1This is doc/gccint.info, produced by makeinfo version 4.12 from 2/space/rguenther/gcc-4.8.5/gcc-4.8.5/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 4.8.5. 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* Funding:: How to help assure funding for free software. 104* GNU Project:: The GNU Project and GNU/Linux. 105 106* Copying:: GNU General Public License says 107 how you can copy and share GCC. 108* GNU Free Documentation License:: How you can copy and share this manual. 109* Contributors:: People who have contributed to GCC. 110 111* Option Index:: Index to command line options. 112* Concept Index:: Index of concepts and symbol names. 113 114 115File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top 116 1171 Contributing to GCC Development 118********************************* 119 120If you would like to help pretest GCC releases to assure they work well, 121current development sources are available by SVN (see 122`http://gcc.gnu.org/svn.html'). Source and binary snapshots are also 123available for FTP; see `http://gcc.gnu.org/snapshots.html'. 124 125 If you would like to work on improvements to GCC, please read the 126advice at these URLs: 127 128 `http://gcc.gnu.org/contribute.html' 129 `http://gcc.gnu.org/contributewhy.html' 130 131for information on how to make useful contributions and avoid 132duplication of effort. Suggested projects are listed at 133`http://gcc.gnu.org/projects/'. 134 135 136File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 137 1382 GCC and Portability 139********************* 140 141GCC itself aims to be portable to any machine where `int' is at least a 14232-bit type. It aims to target machines with a flat (non-segmented) 143byte addressed data address space (the code address space can be 144separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char' 145can be wider than 8 bits. 146 147 GCC gets most of the information about the target machine from a 148machine description which gives an algebraic formula for each of the 149machine's instructions. This is a very clean way to describe the 150target. But when the compiler needs information that is difficult to 151express in this fashion, ad-hoc parameters have been defined for 152machine descriptions. The purpose of portability is to reduce the 153total work needed on the compiler; it was not of interest for its own 154sake. 155 156 GCC does not contain machine dependent code, but it does contain code 157that depends on machine parameters such as endianness (whether the most 158significant byte has the highest or lowest address of the bytes in a 159word) and the availability of autoincrement addressing. In the 160RTL-generation pass, it is often necessary to have multiple strategies 161for generating code for a particular kind of syntax tree, strategies 162that are usable for different combinations of parameters. Often, not 163all possible cases have been addressed, but only the common ones or 164only the ones that have been encountered. As a result, a new target 165may require additional strategies. You will know if this happens 166because the compiler will call `abort'. Fortunately, the new 167strategies can be added in a machine-independent fashion, and will 168affect only the target machines that need them. 169 170 171File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 172 1733 Interfacing to GCC Output 174*************************** 175 176GCC is normally configured to use the same function calling convention 177normally in use on the target system. This is done with the 178machine-description macros described (*note Target Macros::). 179 180 However, returning of structure and union values is done differently on 181some target machines. As a result, functions compiled with PCC 182returning such types cannot be called from code compiled with GCC, and 183vice versa. This does not cause trouble often because few Unix library 184routines return structures or unions. 185 186 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes 187long in the same registers used for `int' or `double' return values. 188(GCC typically allocates variables of such types in registers also.) 189Structures and unions of other sizes are returned by storing them into 190an address passed by the caller (usually in a register). The target 191hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 192 193 By contrast, PCC on most target machines returns structures and unions 194of any size by copying the data into an area of static storage, and then 195returning the address of that storage as if it were a pointer value. 196The caller must copy the data from that memory area to the place where 197the value is wanted. This is slower than the method used by GCC, and 198fails to be reentrant. 199 200 On some target machines, such as RISC machines and the 80386, the 201standard system convention is to pass to the subroutine the address of 202where to return the value. On these machines, GCC has been configured 203to be compatible with the standard compiler, when this method is used. 204It may not be compatible for structures of 1, 2, 4 or 8 bytes. 205 206 GCC uses the system's standard convention for passing arguments. On 207some machines, the first few arguments are passed in registers; in 208others, all are passed on the stack. It would be possible to use 209registers for argument passing on any machine, and this would probably 210result in a significant speedup. But the result would be complete 211incompatibility with code that follows the standard convention. So this 212change is practical only if you are switching to GCC as the sole C 213compiler for the system. We may implement register argument passing on 214certain machines once we have a complete GNU system so that we can 215compile the libraries with GCC. 216 217 On some machines (particularly the SPARC), certain types of arguments 218are passed "by invisible reference". This means that the value is 219stored in memory, and the address of the memory location is passed to 220the subroutine. 221 222 If you use `longjmp', beware of automatic variables. ISO C says that 223automatic variables that are not declared `volatile' have undefined 224values after a `longjmp'. And this is all GCC promises to do, because 225it is very difficult to restore register variables correctly, and one 226of GCC's features is that it can put variables in registers without 227your asking it to. 228 229 230File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 231 2324 The GCC low-level runtime library 233*********************************** 234 235GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1' 236on some platforms. GCC generates calls to routines in this library 237automatically, whenever it needs to perform some operation that is too 238complicated to emit inline code for. 239 240 Most of the routines in `libgcc' handle arithmetic operations that the 241target processor cannot perform directly. This includes integer 242multiply and divide on some machines, and all floating-point and 243fixed-point operations on other machines. `libgcc' also includes 244routines for exception handling, and a handful of miscellaneous 245operations. 246 247 Some of these routines can be defined in mostly machine-independent C. 248Others must be hand-written in assembly language for each processor 249that needs them. 250 251 GCC will also generate calls to C library routines, such as `memcpy' 252and `memset', in some cases. The set of routines that GCC may possibly 253use is documented in *note Other Builtins: (gcc)Other Builtins. 254 255 These routines take arguments and return values of a specific machine 256mode, not a specific C type. *Note Machine Modes::, for an explanation 257of this concept. For illustrative purposes, in this chapter the 258floating point type `float' is assumed to correspond to `SFmode'; 259`double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'. 260Similarly, the integer types `int' and `unsigned int' correspond to 261`SImode'; `long' and `unsigned long' to `DImode'; and `long long' and 262`unsigned long long' to `TImode'. 263 264* Menu: 265 266* Integer library routines:: 267* Soft float library routines:: 268* Decimal float library routines:: 269* Fixed-point fractional library routines:: 270* Exception handling routines:: 271* Miscellaneous routines:: 272 273 274File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 275 2764.1 Routines for integer arithmetic 277=================================== 278 279The integer arithmetic routines are used on platforms that don't provide 280hardware support for arithmetic operations on some modes. 281 2824.1.1 Arithmetic functions 283-------------------------- 284 285 -- Runtime Function: int __ashlsi3 (int A, int B) 286 -- Runtime Function: long __ashldi3 (long A, int B) 287 -- Runtime Function: long long __ashlti3 (long long A, int B) 288 These functions return the result of shifting A left by B bits. 289 290 -- Runtime Function: int __ashrsi3 (int A, int B) 291 -- Runtime Function: long __ashrdi3 (long A, int B) 292 -- Runtime Function: long long __ashrti3 (long long A, int B) 293 These functions return the result of arithmetically shifting A 294 right by B bits. 295 296 -- Runtime Function: int __divsi3 (int A, int B) 297 -- Runtime Function: long __divdi3 (long A, long B) 298 -- Runtime Function: long long __divti3 (long long A, long long B) 299 These functions return the quotient of the signed division of A and 300 B. 301 302 -- Runtime Function: int __lshrsi3 (int A, int B) 303 -- Runtime Function: long __lshrdi3 (long A, int B) 304 -- Runtime Function: long long __lshrti3 (long long A, int B) 305 These functions return the result of logically shifting A right by 306 B bits. 307 308 -- Runtime Function: int __modsi3 (int A, int B) 309 -- Runtime Function: long __moddi3 (long A, long B) 310 -- Runtime Function: long long __modti3 (long long A, long long B) 311 These functions return the remainder of the signed division of A 312 and B. 313 314 -- Runtime Function: int __mulsi3 (int A, int B) 315 -- Runtime Function: long __muldi3 (long A, long B) 316 -- Runtime Function: long long __multi3 (long long A, long long B) 317 These functions return the product of A and B. 318 319 -- Runtime Function: long __negdi2 (long A) 320 -- Runtime Function: long long __negti2 (long long A) 321 These functions return the negation of A. 322 323 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 324 int B) 325 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, 326 unsigned long B) 327 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 328 A, unsigned long long B) 329 These functions return the quotient of the unsigned division of A 330 and B. 331 332 -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A, 333 unsigned long B, unsigned long *C) 334 -- Runtime Function: unsigned long long __udivmodti4 (unsigned long 335 long A, unsigned long long B, unsigned long long *C) 336 These functions calculate both the quotient and remainder of the 337 unsigned division of A and B. The return value is the quotient, 338 and the remainder is placed in variable pointed to by C. 339 340 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 341 int B) 342 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, 343 unsigned long B) 344 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 345 A, unsigned long long B) 346 These functions return the remainder of the unsigned division of A 347 and B. 348 3494.1.2 Comparison functions 350-------------------------- 351 352The following functions implement integral comparisons. These functions 353implement a low-level compare, upon which the higher level comparison 354operators (such as less than and greater than or equal to) can be 355constructed. The returned values lie in the range zero to two, to allow 356the high-level operators to be implemented by testing the returned 357result using either signed or unsigned comparison. 358 359 -- Runtime Function: int __cmpdi2 (long A, long B) 360 -- Runtime Function: int __cmpti2 (long long A, long long B) 361 These functions perform a signed comparison of A and B. If A is 362 less than B, they return 0; if A is greater than B, they return 2; 363 and if A and B are equal they return 1. 364 365 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 366 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned 367 long long B) 368 These functions perform an unsigned comparison of A and B. If A 369 is less than B, they return 0; if A is greater than B, they return 370 2; and if A and B are equal they return 1. 371 3724.1.3 Trapping arithmetic functions 373----------------------------------- 374 375The following functions implement trapping arithmetic. These functions 376call the libc function `abort' upon signed arithmetic overflow. 377 378 -- Runtime Function: int __absvsi2 (int A) 379 -- Runtime Function: long __absvdi2 (long A) 380 These functions return the absolute value of A. 381 382 -- Runtime Function: int __addvsi3 (int A, int B) 383 -- Runtime Function: long __addvdi3 (long A, long B) 384 These functions return the sum of A and B; that is `A + B'. 385 386 -- Runtime Function: int __mulvsi3 (int A, int B) 387 -- Runtime Function: long __mulvdi3 (long A, long B) 388 The functions return the product of A and B; that is `A * B'. 389 390 -- Runtime Function: int __negvsi2 (int A) 391 -- Runtime Function: long __negvdi2 (long A) 392 These functions return the negation of A; that is `-A'. 393 394 -- Runtime Function: int __subvsi3 (int A, int B) 395 -- Runtime Function: long __subvdi3 (long A, long B) 396 These functions return the difference between B and A; that is `A 397 - B'. 398 3994.1.4 Bit operations 400-------------------- 401 402 -- Runtime Function: int __clzsi2 (int A) 403 -- Runtime Function: int __clzdi2 (long A) 404 -- Runtime Function: int __clzti2 (long long A) 405 These functions return the number of leading 0-bits in A, starting 406 at the most significant bit position. If A is zero, the result is 407 undefined. 408 409 -- Runtime Function: int __ctzsi2 (int A) 410 -- Runtime Function: int __ctzdi2 (long A) 411 -- Runtime Function: int __ctzti2 (long long A) 412 These functions return the number of trailing 0-bits in A, starting 413 at the least significant bit position. If A is zero, the result is 414 undefined. 415 416 -- Runtime Function: int __ffsdi2 (long A) 417 -- Runtime Function: int __ffsti2 (long long A) 418 These functions return the index of the least significant 1-bit in 419 A, or the value zero if A is zero. The least significant bit is 420 index one. 421 422 -- Runtime Function: int __paritysi2 (int A) 423 -- Runtime Function: int __paritydi2 (long A) 424 -- Runtime Function: int __parityti2 (long long A) 425 These functions return the value zero if the number of bits set in 426 A is even, and the value one otherwise. 427 428 -- Runtime Function: int __popcountsi2 (int A) 429 -- Runtime Function: int __popcountdi2 (long A) 430 -- Runtime Function: int __popcountti2 (long long A) 431 These functions return the number of bits set in A. 432 433 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 434 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 435 These functions return the A byteswapped. 436 437 438File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 439 4404.2 Routines for floating point emulation 441========================================= 442 443The software floating point library is used on machines which do not 444have hardware support for floating point. It is also used whenever 445`-msoft-float' is used to disable generation of floating point 446instructions. (Not all targets support this switch.) 447 448 For compatibility with other compilers, the floating point emulation 449routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note 450Library Calls::). In this section, the default names are used. 451 452 Presently the library does not support `XFmode', which is used for 453`long double' on some architectures. 454 4554.2.1 Arithmetic functions 456-------------------------- 457 458 -- Runtime Function: float __addsf3 (float A, float B) 459 -- Runtime Function: double __adddf3 (double A, double B) 460 -- Runtime Function: long double __addtf3 (long double A, long double 461 B) 462 -- Runtime Function: long double __addxf3 (long double A, long double 463 B) 464 These functions return the sum of A and B. 465 466 -- Runtime Function: float __subsf3 (float A, float B) 467 -- Runtime Function: double __subdf3 (double A, double B) 468 -- Runtime Function: long double __subtf3 (long double A, long double 469 B) 470 -- Runtime Function: long double __subxf3 (long double A, long double 471 B) 472 These functions return the difference between B and A; that is, 473 A - B. 474 475 -- Runtime Function: float __mulsf3 (float A, float B) 476 -- Runtime Function: double __muldf3 (double A, double B) 477 -- Runtime Function: long double __multf3 (long double A, long double 478 B) 479 -- Runtime Function: long double __mulxf3 (long double A, long double 480 B) 481 These functions return the product of A and B. 482 483 -- Runtime Function: float __divsf3 (float A, float B) 484 -- Runtime Function: double __divdf3 (double A, double B) 485 -- Runtime Function: long double __divtf3 (long double A, long double 486 B) 487 -- Runtime Function: long double __divxf3 (long double A, long double 488 B) 489 These functions return the quotient of A and B; that is, A / B. 490 491 -- Runtime Function: float __negsf2 (float A) 492 -- Runtime Function: double __negdf2 (double A) 493 -- Runtime Function: long double __negtf2 (long double A) 494 -- Runtime Function: long double __negxf2 (long double A) 495 These functions return the negation of A. They simply flip the 496 sign bit, so they can produce negative zero and negative NaN. 497 4984.2.2 Conversion functions 499-------------------------- 500 501 -- Runtime Function: double __extendsfdf2 (float A) 502 -- Runtime Function: long double __extendsftf2 (float A) 503 -- Runtime Function: long double __extendsfxf2 (float A) 504 -- Runtime Function: long double __extenddftf2 (double A) 505 -- Runtime Function: long double __extenddfxf2 (double A) 506 These functions extend A to the wider mode of their return type. 507 508 -- Runtime Function: double __truncxfdf2 (long double A) 509 -- Runtime Function: double __trunctfdf2 (long double A) 510 -- Runtime Function: float __truncxfsf2 (long double A) 511 -- Runtime Function: float __trunctfsf2 (long double A) 512 -- Runtime Function: float __truncdfsf2 (double A) 513 These functions truncate A to the narrower mode of their return 514 type, rounding toward zero. 515 516 -- Runtime Function: int __fixsfsi (float A) 517 -- Runtime Function: int __fixdfsi (double A) 518 -- Runtime Function: int __fixtfsi (long double A) 519 -- Runtime Function: int __fixxfsi (long double A) 520 These functions convert A to a signed integer, rounding toward 521 zero. 522 523 -- Runtime Function: long __fixsfdi (float A) 524 -- Runtime Function: long __fixdfdi (double A) 525 -- Runtime Function: long __fixtfdi (long double A) 526 -- Runtime Function: long __fixxfdi (long double A) 527 These functions convert A to a signed long, rounding toward zero. 528 529 -- Runtime Function: long long __fixsfti (float A) 530 -- Runtime Function: long long __fixdfti (double A) 531 -- Runtime Function: long long __fixtfti (long double A) 532 -- Runtime Function: long long __fixxfti (long double A) 533 These functions convert A to a signed long long, rounding toward 534 zero. 535 536 -- Runtime Function: unsigned int __fixunssfsi (float A) 537 -- Runtime Function: unsigned int __fixunsdfsi (double A) 538 -- Runtime Function: unsigned int __fixunstfsi (long double A) 539 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 540 These functions convert A to an unsigned integer, rounding toward 541 zero. Negative values all become zero. 542 543 -- Runtime Function: unsigned long __fixunssfdi (float A) 544 -- Runtime Function: unsigned long __fixunsdfdi (double A) 545 -- Runtime Function: unsigned long __fixunstfdi (long double A) 546 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 547 These functions convert A to an unsigned long, rounding toward 548 zero. Negative values all become zero. 549 550 -- Runtime Function: unsigned long long __fixunssfti (float A) 551 -- Runtime Function: unsigned long long __fixunsdfti (double A) 552 -- Runtime Function: unsigned long long __fixunstfti (long double A) 553 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 554 These functions convert A to an unsigned long long, rounding 555 toward zero. Negative values all become zero. 556 557 -- Runtime Function: float __floatsisf (int I) 558 -- Runtime Function: double __floatsidf (int I) 559 -- Runtime Function: long double __floatsitf (int I) 560 -- Runtime Function: long double __floatsixf (int I) 561 These functions convert I, a signed integer, to floating point. 562 563 -- Runtime Function: float __floatdisf (long I) 564 -- Runtime Function: double __floatdidf (long I) 565 -- Runtime Function: long double __floatditf (long I) 566 -- Runtime Function: long double __floatdixf (long I) 567 These functions convert I, a signed long, to floating point. 568 569 -- Runtime Function: float __floattisf (long long I) 570 -- Runtime Function: double __floattidf (long long I) 571 -- Runtime Function: long double __floattitf (long long I) 572 -- Runtime Function: long double __floattixf (long long I) 573 These functions convert I, a signed long long, to floating point. 574 575 -- Runtime Function: float __floatunsisf (unsigned int I) 576 -- Runtime Function: double __floatunsidf (unsigned int I) 577 -- Runtime Function: long double __floatunsitf (unsigned int I) 578 -- Runtime Function: long double __floatunsixf (unsigned int I) 579 These functions convert I, an unsigned integer, to floating point. 580 581 -- Runtime Function: float __floatundisf (unsigned long I) 582 -- Runtime Function: double __floatundidf (unsigned long I) 583 -- Runtime Function: long double __floatunditf (unsigned long I) 584 -- Runtime Function: long double __floatundixf (unsigned long I) 585 These functions convert I, an unsigned long, to floating point. 586 587 -- Runtime Function: float __floatuntisf (unsigned long long I) 588 -- Runtime Function: double __floatuntidf (unsigned long long I) 589 -- Runtime Function: long double __floatuntitf (unsigned long long I) 590 -- Runtime Function: long double __floatuntixf (unsigned long long I) 591 These functions convert I, an unsigned long long, to floating 592 point. 593 5944.2.3 Comparison functions 595-------------------------- 596 597There are two sets of basic comparison functions. 598 599 -- Runtime Function: int __cmpsf2 (float A, float B) 600 -- Runtime Function: int __cmpdf2 (double A, double B) 601 -- Runtime Function: int __cmptf2 (long double A, long double B) 602 These functions calculate a <=> b. That is, if A is less than B, 603 they return -1; if A is greater than B, they return 1; and if A 604 and B are equal they return 0. If either argument is NaN they 605 return 1, but you should not rely on this; if NaN is a 606 possibility, use one of the higher-level comparison functions. 607 608 -- Runtime Function: int __unordsf2 (float A, float B) 609 -- Runtime Function: int __unorddf2 (double A, double B) 610 -- Runtime Function: int __unordtf2 (long double A, long double B) 611 These functions return a nonzero value if either argument is NaN, 612 otherwise 0. 613 614 There is also a complete group of higher level functions which 615correspond directly to comparison operators. They implement the ISO C 616semantics for floating-point comparisons, taking NaN into account. Pay 617careful attention to the return values defined for each set. Under the 618hood, all of these routines are implemented as 619 620 if (__unordXf2 (a, b)) 621 return E; 622 return __cmpXf2 (a, b); 623 624where E is a constant chosen to give the proper behavior for NaN. 625Thus, the meaning of the return value is different for each set. Do 626not rely on this implementation; only the semantics documented below 627are guaranteed. 628 629 -- Runtime Function: int __eqsf2 (float A, float B) 630 -- Runtime Function: int __eqdf2 (double A, double B) 631 -- Runtime Function: int __eqtf2 (long double A, long double B) 632 These functions return zero if neither argument is NaN, and A and 633 B are equal. 634 635 -- Runtime Function: int __nesf2 (float A, float B) 636 -- Runtime Function: int __nedf2 (double A, double B) 637 -- Runtime Function: int __netf2 (long double A, long double B) 638 These functions return a nonzero value if either argument is NaN, 639 or if A and B are unequal. 640 641 -- Runtime Function: int __gesf2 (float A, float B) 642 -- Runtime Function: int __gedf2 (double A, double B) 643 -- Runtime Function: int __getf2 (long double A, long double B) 644 These functions return a value greater than or equal to zero if 645 neither argument is NaN, and A is greater than or equal to B. 646 647 -- Runtime Function: int __ltsf2 (float A, float B) 648 -- Runtime Function: int __ltdf2 (double A, double B) 649 -- Runtime Function: int __lttf2 (long double A, long double B) 650 These functions return a value less than zero if neither argument 651 is NaN, and A is strictly less than B. 652 653 -- Runtime Function: int __lesf2 (float A, float B) 654 -- Runtime Function: int __ledf2 (double A, double B) 655 -- Runtime Function: int __letf2 (long double A, long double B) 656 These functions return a value less than or equal to zero if 657 neither argument is NaN, and A is less than or equal to B. 658 659 -- Runtime Function: int __gtsf2 (float A, float B) 660 -- Runtime Function: int __gtdf2 (double A, double B) 661 -- Runtime Function: int __gttf2 (long double A, long double B) 662 These functions return a value greater than zero if neither 663 argument is NaN, and A is strictly greater than B. 664 6654.2.4 Other floating-point functions 666------------------------------------ 667 668 -- Runtime Function: float __powisf2 (float A, int B) 669 -- Runtime Function: double __powidf2 (double A, int B) 670 -- Runtime Function: long double __powitf2 (long double A, int B) 671 -- Runtime Function: long double __powixf2 (long double A, int B) 672 These functions convert raise A to the power B. 673 674 -- Runtime Function: complex float __mulsc3 (float A, float B, float 675 C, float D) 676 -- Runtime Function: complex double __muldc3 (double A, double B, 677 double C, double D) 678 -- Runtime Function: complex long double __multc3 (long double A, long 679 double B, long double C, long double D) 680 -- Runtime Function: complex long double __mulxc3 (long double A, long 681 double B, long double C, long double D) 682 These functions return the product of A + iB and C + iD, following 683 the rules of C99 Annex G. 684 685 -- Runtime Function: complex float __divsc3 (float A, float B, float 686 C, float D) 687 -- Runtime Function: complex double __divdc3 (double A, double B, 688 double C, double D) 689 -- Runtime Function: complex long double __divtc3 (long double A, long 690 double B, long double C, long double D) 691 -- Runtime Function: complex long double __divxc3 (long double A, long 692 double B, long double C, long double D) 693 These functions return the quotient of A + iB and C + iD (i.e., (A 694 + iB) / (C + iD)), following the rules of C99 Annex G. 695 696 697File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 698 6994.3 Routines for decimal floating point emulation 700================================================= 701 702The software decimal floating point library implements IEEE 754-2008 703decimal floating point arithmetic and is only activated on selected 704targets. 705 706 The software decimal floating point library supports either DPD 707(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 708selected at configure time. 709 7104.3.1 Arithmetic functions 711-------------------------- 712 713 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 714 B) 715 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 716 B) 717 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 718 B) 719 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 720 B) 721 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 722 _Decimal128 B) 723 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 724 _Decimal128 B) 725 These functions return the sum of A and B. 726 727 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 728 B) 729 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 730 B) 731 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 732 B) 733 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 734 B) 735 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 736 _Decimal128 B) 737 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 738 _Decimal128 B) 739 These functions return the difference between B and A; that is, 740 A - B. 741 742 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 743 B) 744 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 745 B) 746 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 747 B) 748 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 749 B) 750 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 751 _Decimal128 B) 752 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 753 _Decimal128 B) 754 These functions return the product of A and B. 755 756 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 757 B) 758 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 759 B) 760 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 761 B) 762 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 763 B) 764 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 765 _Decimal128 B) 766 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 767 _Decimal128 B) 768 These functions return the quotient of A and B; that is, A / B. 769 770 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 771 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 772 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 773 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 774 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 775 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 776 These functions return the negation of A. They simply flip the 777 sign bit, so they can produce negative zero and negative NaN. 778 7794.3.2 Conversion functions 780-------------------------- 781 782 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 783 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 784 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 785 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 786 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 787 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 788 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 789 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 790 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 791 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 792 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 793 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 794 These functions convert the value A from one decimal floating type 795 to another. 796 797 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 798 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 799 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 800 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 801 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 802 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 803 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 804 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 805 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 806 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 807 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 808 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 809 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 810 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 811 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 812 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 813 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 814 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 815 These functions convert the value of A from a binary floating type 816 to a decimal floating type of a different size. 817 818 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 819 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 820 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 821 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 822 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 823 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 824 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 825 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 826 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 827 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 828 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 829 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 830 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 831 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 832 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 833 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 834 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 835 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 836 These functions convert the value of A from a decimal floating type 837 to a binary floating type of a different size. 838 839 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 840 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 841 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 842 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 843 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 844 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 845 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 846 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 847 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 848 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 849 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 850 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 851 These functions convert the value of A between decimal and binary 852 floating types of the same size. 853 854 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 855 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 856 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 857 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 858 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 859 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 860 These functions convert A to a signed integer. 861 862 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 863 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 864 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 865 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 866 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 867 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 868 These functions convert A to a signed long. 869 870 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 871 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 872 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 873 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 874 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 875 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 876 These functions convert A to an unsigned integer. Negative values 877 all become zero. 878 879 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 880 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 881 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 882 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 883 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 884 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 885 These functions convert A to an unsigned long. Negative values 886 all become zero. 887 888 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 889 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 890 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 891 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 892 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 893 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 894 These functions convert I, a signed integer, to decimal floating 895 point. 896 897 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 898 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 899 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 900 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 901 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 902 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 903 These functions convert I, a signed long, to decimal floating 904 point. 905 906 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 907 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 908 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 909 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 910 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 911 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 912 These functions convert I, an unsigned integer, to decimal 913 floating point. 914 915 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 916 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 917 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 918 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 919 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 920 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 921 These functions convert I, an unsigned long, to decimal floating 922 point. 923 9244.3.3 Comparison functions 925-------------------------- 926 927 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 928 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 929 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 930 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 931 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 932 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 933 These functions return a nonzero value if either argument is NaN, 934 otherwise 0. 935 936 There is also a complete group of higher level functions which 937correspond directly to comparison operators. They implement the ISO C 938semantics for floating-point comparisons, taking NaN into account. Pay 939careful attention to the return values defined for each set. Under the 940hood, all of these routines are implemented as 941 942 if (__bid_unordXd2 (a, b)) 943 return E; 944 return __bid_cmpXd2 (a, b); 945 946where E is a constant chosen to give the proper behavior for NaN. 947Thus, the meaning of the return value is different for each set. Do 948not rely on this implementation; only the semantics documented below 949are guaranteed. 950 951 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 952 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 953 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 954 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 955 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 956 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 957 These functions return zero if neither argument is NaN, and A and 958 B are equal. 959 960 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 961 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 962 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 963 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 964 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 965 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 966 These functions return a nonzero value if either argument is NaN, 967 or if A and B are unequal. 968 969 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 970 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 971 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 972 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 973 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 974 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 975 These functions return a value greater than or equal to zero if 976 neither argument is NaN, and A is greater than or equal to B. 977 978 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 979 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 980 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 981 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 982 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 983 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 984 These functions return a value less than zero if neither argument 985 is NaN, and A is strictly less than B. 986 987 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 988 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 989 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 990 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 991 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 992 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 993 These functions return a value less than or equal to zero if 994 neither argument is NaN, and A is less than or equal to B. 995 996 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 997 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 998 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 999 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 1000 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1001 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1002 These functions return a value greater than zero if neither 1003 argument is NaN, and A is strictly greater than B. 1004 1005 1006File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1007 10084.4 Routines for fixed-point fractional emulation 1009================================================= 1010 1011The software fixed-point library implements fixed-point fractional 1012arithmetic, and is only activated on selected targets. 1013 1014 For ease of comprehension `fract' is an alias for the `_Fract' type, 1015`accum' an alias for `_Accum', and `sat' an alias for `_Sat'. 1016 1017 For illustrative purposes, in this section the fixed-point fractional 1018type `short fract' is assumed to correspond to machine mode `QQmode'; 1019`unsigned short fract' to `UQQmode'; `fract' to `HQmode'; 1020`unsigned fract' to `UHQmode'; `long fract' to `SQmode'; 1021`unsigned long fract' to `USQmode'; `long long fract' to `DQmode'; and 1022`unsigned long long fract' to `UDQmode'. Similarly the fixed-point 1023accumulator type `short accum' corresponds to `HAmode'; 1024`unsigned short accum' to `UHAmode'; `accum' to `SAmode'; 1025`unsigned accum' to `USAmode'; `long accum' to `DAmode'; 1026`unsigned long accum' to `UDAmode'; `long long accum' to `TAmode'; and 1027`unsigned long long accum' to `UTAmode'. 1028 10294.4.1 Arithmetic functions 1030-------------------------- 1031 1032 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1033 B) 1034 -- Runtime Function: fract __addhq3 (fract A, fract B) 1035 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1036 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1037 long fract B) 1038 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1039 fract A, unsigned short fract B) 1040 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1041 unsigned fract B) 1042 -- Runtime Function: unsigned long fract __addusq3 (unsigned long 1043 fract A, unsigned long fract B) 1044 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1045 long fract A, unsigned long long fract B) 1046 -- Runtime Function: short accum __addha3 (short accum A, short accum 1047 B) 1048 -- Runtime Function: accum __addsa3 (accum A, accum B) 1049 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1050 -- Runtime Function: long long accum __addta3 (long long accum A, long 1051 long accum B) 1052 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1053 accum A, unsigned short accum B) 1054 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1055 unsigned accum B) 1056 -- Runtime Function: unsigned long accum __adduda3 (unsigned long 1057 accum A, unsigned long accum B) 1058 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1059 long accum A, unsigned long long accum B) 1060 These functions return the sum of A and B. 1061 1062 -- Runtime Function: short fract __ssaddqq3 (short fract A, short 1063 fract B) 1064 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1065 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1066 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1067 long long fract B) 1068 -- Runtime Function: short accum __ssaddha3 (short accum A, short 1069 accum B) 1070 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1071 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1072 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1073 long long accum B) 1074 These functions return the sum of A and B with signed saturation. 1075 1076 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1077 fract A, unsigned short fract B) 1078 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1079 unsigned fract B) 1080 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1081 fract A, unsigned long fract B) 1082 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1083 long long fract A, unsigned long long fract B) 1084 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1085 accum A, unsigned short accum B) 1086 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1087 unsigned accum B) 1088 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1089 accum A, unsigned long accum B) 1090 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1091 long long accum A, unsigned long long accum B) 1092 These functions return the sum of A and B with unsigned saturation. 1093 1094 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1095 B) 1096 -- Runtime Function: fract __subhq3 (fract A, fract B) 1097 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1098 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1099 long fract B) 1100 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1101 fract A, unsigned short fract B) 1102 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1103 unsigned fract B) 1104 -- Runtime Function: unsigned long fract __subusq3 (unsigned long 1105 fract A, unsigned long fract B) 1106 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1107 long fract A, unsigned long long fract B) 1108 -- Runtime Function: short accum __subha3 (short accum A, short accum 1109 B) 1110 -- Runtime Function: accum __subsa3 (accum A, accum B) 1111 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1112 -- Runtime Function: long long accum __subta3 (long long accum A, long 1113 long accum B) 1114 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1115 accum A, unsigned short accum B) 1116 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1117 unsigned accum B) 1118 -- Runtime Function: unsigned long accum __subuda3 (unsigned long 1119 accum A, unsigned long accum B) 1120 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1121 long accum A, unsigned long long accum B) 1122 These functions return the difference of A and B; that is, `A - B'. 1123 1124 -- Runtime Function: short fract __sssubqq3 (short fract A, short 1125 fract B) 1126 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1127 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1128 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1129 long long fract B) 1130 -- Runtime Function: short accum __sssubha3 (short accum A, short 1131 accum B) 1132 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1133 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1134 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1135 long long accum B) 1136 These functions return the difference of A and B with signed 1137 saturation; that is, `A - B'. 1138 1139 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1140 fract A, unsigned short fract B) 1141 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1142 unsigned fract B) 1143 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1144 fract A, unsigned long fract B) 1145 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1146 long long fract A, unsigned long long fract B) 1147 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1148 accum A, unsigned short accum B) 1149 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1150 unsigned accum B) 1151 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1152 accum A, unsigned long accum B) 1153 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1154 long long accum A, unsigned long long accum B) 1155 These functions return the difference of A and B with unsigned 1156 saturation; that is, `A - B'. 1157 1158 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1159 B) 1160 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1161 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1162 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1163 long fract B) 1164 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1165 fract A, unsigned short fract B) 1166 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1167 unsigned fract B) 1168 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long 1169 fract A, unsigned long fract B) 1170 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1171 long fract A, unsigned long long fract B) 1172 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1173 B) 1174 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1175 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1176 -- Runtime Function: long long accum __multa3 (long long accum A, long 1177 long accum B) 1178 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1179 accum A, unsigned short accum B) 1180 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1181 unsigned accum B) 1182 -- Runtime Function: unsigned long accum __muluda3 (unsigned long 1183 accum A, unsigned long accum B) 1184 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1185 long accum A, unsigned long long accum B) 1186 These functions return the product of A and B. 1187 1188 -- Runtime Function: short fract __ssmulqq3 (short fract A, short 1189 fract B) 1190 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1191 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1192 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1193 long long fract B) 1194 -- Runtime Function: short accum __ssmulha3 (short accum A, short 1195 accum B) 1196 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1197 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1198 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1199 long long accum B) 1200 These functions return the product of A and B with signed 1201 saturation. 1202 1203 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1204 fract A, unsigned short fract B) 1205 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1206 unsigned fract B) 1207 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1208 fract A, unsigned long fract B) 1209 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1210 long long fract A, unsigned long long fract B) 1211 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1212 accum A, unsigned short accum B) 1213 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1214 unsigned accum B) 1215 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1216 accum A, unsigned long accum B) 1217 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1218 long long accum A, unsigned long long accum B) 1219 These functions return the product of A and B with unsigned 1220 saturation. 1221 1222 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1223 B) 1224 -- Runtime Function: fract __divhq3 (fract A, fract B) 1225 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1226 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1227 long fract B) 1228 -- Runtime Function: short accum __divha3 (short accum A, short accum 1229 B) 1230 -- Runtime Function: accum __divsa3 (accum A, accum B) 1231 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1232 -- Runtime Function: long long accum __divta3 (long long accum A, long 1233 long accum B) 1234 These functions return the quotient of the signed division of A 1235 and B. 1236 1237 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1238 fract A, unsigned short fract B) 1239 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1240 unsigned fract B) 1241 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1242 fract A, unsigned long fract B) 1243 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned 1244 long long fract A, unsigned long long fract B) 1245 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1246 accum A, unsigned short accum B) 1247 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1248 unsigned accum B) 1249 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1250 accum A, unsigned long accum B) 1251 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned 1252 long long accum A, unsigned long long accum B) 1253 These functions return the quotient of the unsigned division of A 1254 and B. 1255 1256 -- Runtime Function: short fract __ssdivqq3 (short fract A, short 1257 fract B) 1258 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1259 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1260 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1261 long long fract B) 1262 -- Runtime Function: short accum __ssdivha3 (short accum A, short 1263 accum B) 1264 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1265 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1266 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1267 long long accum B) 1268 These functions return the quotient of the signed division of A 1269 and B with signed saturation. 1270 1271 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1272 fract A, unsigned short fract B) 1273 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1274 unsigned fract B) 1275 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1276 fract A, unsigned long fract B) 1277 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1278 long long fract A, unsigned long long fract B) 1279 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1280 accum A, unsigned short accum B) 1281 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1282 unsigned accum B) 1283 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1284 accum A, unsigned long accum B) 1285 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1286 long long accum A, unsigned long long accum B) 1287 These functions return the quotient of the unsigned division of A 1288 and B with unsigned saturation. 1289 1290 -- Runtime Function: short fract __negqq2 (short fract A) 1291 -- Runtime Function: fract __neghq2 (fract A) 1292 -- Runtime Function: long fract __negsq2 (long fract A) 1293 -- Runtime Function: long long fract __negdq2 (long long fract A) 1294 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1295 fract A) 1296 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1297 -- Runtime Function: unsigned long fract __negusq2 (unsigned long 1298 fract A) 1299 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1300 long fract A) 1301 -- Runtime Function: short accum __negha2 (short accum A) 1302 -- Runtime Function: accum __negsa2 (accum A) 1303 -- Runtime Function: long accum __negda2 (long accum A) 1304 -- Runtime Function: long long accum __negta2 (long long accum A) 1305 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1306 accum A) 1307 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1308 -- Runtime Function: unsigned long accum __neguda2 (unsigned long 1309 accum A) 1310 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1311 long accum A) 1312 These functions return the negation of A. 1313 1314 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1315 -- Runtime Function: fract __ssneghq2 (fract A) 1316 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1317 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1318 -- Runtime Function: short accum __ssnegha2 (short accum A) 1319 -- Runtime Function: accum __ssnegsa2 (accum A) 1320 -- Runtime Function: long accum __ssnegda2 (long accum A) 1321 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1322 These functions return the negation of A with signed saturation. 1323 1324 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1325 fract A) 1326 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1327 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1328 fract A) 1329 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1330 long long fract A) 1331 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1332 accum A) 1333 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1334 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1335 accum A) 1336 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1337 long long accum A) 1338 These functions return the negation of A with unsigned saturation. 1339 1340 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1341 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1342 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1343 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1344 B) 1345 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1346 fract A, int B) 1347 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1348 B) 1349 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1350 fract A, int B) 1351 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned 1352 long long fract A, int B) 1353 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1354 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1355 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1356 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1357 B) 1358 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1359 accum A, int B) 1360 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1361 B) 1362 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1363 accum A, int B) 1364 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned 1365 long long accum A, int B) 1366 These functions return the result of shifting A left by B bits. 1367 1368 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1369 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1370 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1371 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1372 B) 1373 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1374 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1375 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1376 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1377 B) 1378 These functions return the result of arithmetically shifting A 1379 right by B bits. 1380 1381 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1382 fract A, int B) 1383 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1384 B) 1385 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1386 fract A, int B) 1387 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned 1388 long long fract A, int B) 1389 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1390 accum A, int B) 1391 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1392 B) 1393 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1394 accum A, int B) 1395 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned 1396 long long accum A, int B) 1397 These functions return the result of logically shifting A right by 1398 B bits. 1399 1400 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1401 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1402 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1403 int B) 1404 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1405 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1406 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1407 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1408 int B) 1409 These functions return the result of shifting A left by B bits 1410 with signed saturation. 1411 1412 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1413 fract A, int B) 1414 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, 1415 int B) 1416 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1417 fract A, int B) 1418 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1419 long long fract A, int B) 1420 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1421 accum A, int B) 1422 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, 1423 int B) 1424 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1425 accum A, int B) 1426 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1427 long long accum A, int B) 1428 These functions return the result of shifting A left by B bits 1429 with unsigned saturation. 1430 14314.4.2 Comparison functions 1432-------------------------- 1433 1434The following functions implement fixed-point comparisons. These 1435functions implement a low-level compare, upon which the higher level 1436comparison operators (such as less than and greater than or equal to) 1437can be constructed. The returned values lie in the range zero to two, 1438to allow the high-level operators to be implemented by testing the 1439returned result using either signed or unsigned comparison. 1440 1441 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1442 -- Runtime Function: int __cmphq2 (fract A, fract B) 1443 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1444 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1445 B) 1446 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1447 short fract B) 1448 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1449 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1450 long fract B) 1451 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1452 unsigned long long fract B) 1453 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1454 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1455 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1456 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1457 B) 1458 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1459 short accum B) 1460 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1461 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1462 long accum B) 1463 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1464 unsigned long long accum B) 1465 These functions perform a signed or unsigned comparison of A and B 1466 (depending on the selected machine mode). If A is less than B, 1467 they return 0; if A is greater than B, they return 2; and if A and 1468 B are equal they return 1. 1469 14704.4.3 Conversion functions 1471-------------------------- 1472 1473 -- Runtime Function: fract __fractqqhq2 (short fract A) 1474 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1475 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1476 -- Runtime Function: short accum __fractqqha (short fract A) 1477 -- Runtime Function: accum __fractqqsa (short fract A) 1478 -- Runtime Function: long accum __fractqqda (short fract A) 1479 -- Runtime Function: long long accum __fractqqta (short fract A) 1480 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1481 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1482 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1483 -- Runtime Function: unsigned long long fract __fractqqudq (short 1484 fract A) 1485 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1486 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1487 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1488 -- Runtime Function: unsigned long long accum __fractqquta (short 1489 fract A) 1490 -- Runtime Function: signed char __fractqqqi (short fract A) 1491 -- Runtime Function: short __fractqqhi (short fract A) 1492 -- Runtime Function: int __fractqqsi (short fract A) 1493 -- Runtime Function: long __fractqqdi (short fract A) 1494 -- Runtime Function: long long __fractqqti (short fract A) 1495 -- Runtime Function: float __fractqqsf (short fract A) 1496 -- Runtime Function: double __fractqqdf (short fract A) 1497 -- Runtime Function: short fract __fracthqqq2 (fract A) 1498 -- Runtime Function: long fract __fracthqsq2 (fract A) 1499 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1500 -- Runtime Function: short accum __fracthqha (fract A) 1501 -- Runtime Function: accum __fracthqsa (fract A) 1502 -- Runtime Function: long accum __fracthqda (fract A) 1503 -- Runtime Function: long long accum __fracthqta (fract A) 1504 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1505 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1506 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1507 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1508 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1509 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1510 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1511 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1512 -- Runtime Function: signed char __fracthqqi (fract A) 1513 -- Runtime Function: short __fracthqhi (fract A) 1514 -- Runtime Function: int __fracthqsi (fract A) 1515 -- Runtime Function: long __fracthqdi (fract A) 1516 -- Runtime Function: long long __fracthqti (fract A) 1517 -- Runtime Function: float __fracthqsf (fract A) 1518 -- Runtime Function: double __fracthqdf (fract A) 1519 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1520 -- Runtime Function: fract __fractsqhq2 (long fract A) 1521 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1522 -- Runtime Function: short accum __fractsqha (long fract A) 1523 -- Runtime Function: accum __fractsqsa (long fract A) 1524 -- Runtime Function: long accum __fractsqda (long fract A) 1525 -- Runtime Function: long long accum __fractsqta (long fract A) 1526 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1527 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1528 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1529 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1530 A) 1531 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1532 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1533 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1534 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1535 A) 1536 -- Runtime Function: signed char __fractsqqi (long fract A) 1537 -- Runtime Function: short __fractsqhi (long fract A) 1538 -- Runtime Function: int __fractsqsi (long fract A) 1539 -- Runtime Function: long __fractsqdi (long fract A) 1540 -- Runtime Function: long long __fractsqti (long fract A) 1541 -- Runtime Function: float __fractsqsf (long fract A) 1542 -- Runtime Function: double __fractsqdf (long fract A) 1543 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1544 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1545 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1546 -- Runtime Function: short accum __fractdqha (long long fract A) 1547 -- Runtime Function: accum __fractdqsa (long long fract A) 1548 -- Runtime Function: long accum __fractdqda (long long fract A) 1549 -- Runtime Function: long long accum __fractdqta (long long fract A) 1550 -- Runtime Function: unsigned short fract __fractdquqq (long long 1551 fract A) 1552 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1553 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1554 A) 1555 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1556 fract A) 1557 -- Runtime Function: unsigned short accum __fractdquha (long long 1558 fract A) 1559 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1560 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1561 A) 1562 -- Runtime Function: unsigned long long accum __fractdquta (long long 1563 fract A) 1564 -- Runtime Function: signed char __fractdqqi (long long fract A) 1565 -- Runtime Function: short __fractdqhi (long long fract A) 1566 -- Runtime Function: int __fractdqsi (long long fract A) 1567 -- Runtime Function: long __fractdqdi (long long fract A) 1568 -- Runtime Function: long long __fractdqti (long long fract A) 1569 -- Runtime Function: float __fractdqsf (long long fract A) 1570 -- Runtime Function: double __fractdqdf (long long fract A) 1571 -- Runtime Function: short fract __fracthaqq (short accum A) 1572 -- Runtime Function: fract __fracthahq (short accum A) 1573 -- Runtime Function: long fract __fracthasq (short accum A) 1574 -- Runtime Function: long long fract __fracthadq (short accum A) 1575 -- Runtime Function: accum __fracthasa2 (short accum A) 1576 -- Runtime Function: long accum __fracthada2 (short accum A) 1577 -- Runtime Function: long long accum __fracthata2 (short accum A) 1578 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1579 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1580 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1581 -- Runtime Function: unsigned long long fract __fracthaudq (short 1582 accum A) 1583 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1584 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1585 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1586 -- Runtime Function: unsigned long long accum __fracthauta (short 1587 accum A) 1588 -- Runtime Function: signed char __fracthaqi (short accum A) 1589 -- Runtime Function: short __fracthahi (short accum A) 1590 -- Runtime Function: int __fracthasi (short accum A) 1591 -- Runtime Function: long __fracthadi (short accum A) 1592 -- Runtime Function: long long __fracthati (short accum A) 1593 -- Runtime Function: float __fracthasf (short accum A) 1594 -- Runtime Function: double __fracthadf (short accum A) 1595 -- Runtime Function: short fract __fractsaqq (accum A) 1596 -- Runtime Function: fract __fractsahq (accum A) 1597 -- Runtime Function: long fract __fractsasq (accum A) 1598 -- Runtime Function: long long fract __fractsadq (accum A) 1599 -- Runtime Function: short accum __fractsaha2 (accum A) 1600 -- Runtime Function: long accum __fractsada2 (accum A) 1601 -- Runtime Function: long long accum __fractsata2 (accum A) 1602 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1603 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1604 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1605 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1606 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1607 -- Runtime Function: unsigned accum __fractsausa (accum A) 1608 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1609 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1610 -- Runtime Function: signed char __fractsaqi (accum A) 1611 -- Runtime Function: short __fractsahi (accum A) 1612 -- Runtime Function: int __fractsasi (accum A) 1613 -- Runtime Function: long __fractsadi (accum A) 1614 -- Runtime Function: long long __fractsati (accum A) 1615 -- Runtime Function: float __fractsasf (accum A) 1616 -- Runtime Function: double __fractsadf (accum A) 1617 -- Runtime Function: short fract __fractdaqq (long accum A) 1618 -- Runtime Function: fract __fractdahq (long accum A) 1619 -- Runtime Function: long fract __fractdasq (long accum A) 1620 -- Runtime Function: long long fract __fractdadq (long accum A) 1621 -- Runtime Function: short accum __fractdaha2 (long accum A) 1622 -- Runtime Function: accum __fractdasa2 (long accum A) 1623 -- Runtime Function: long long accum __fractdata2 (long accum A) 1624 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1625 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1626 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1627 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1628 A) 1629 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1630 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1631 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1632 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1633 A) 1634 -- Runtime Function: signed char __fractdaqi (long accum A) 1635 -- Runtime Function: short __fractdahi (long accum A) 1636 -- Runtime Function: int __fractdasi (long accum A) 1637 -- Runtime Function: long __fractdadi (long accum A) 1638 -- Runtime Function: long long __fractdati (long accum A) 1639 -- Runtime Function: float __fractdasf (long accum A) 1640 -- Runtime Function: double __fractdadf (long accum A) 1641 -- Runtime Function: short fract __fracttaqq (long long accum A) 1642 -- Runtime Function: fract __fracttahq (long long accum A) 1643 -- Runtime Function: long fract __fracttasq (long long accum A) 1644 -- Runtime Function: long long fract __fracttadq (long long accum A) 1645 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1646 -- Runtime Function: accum __fracttasa2 (long long accum A) 1647 -- Runtime Function: long accum __fracttada2 (long long accum A) 1648 -- Runtime Function: unsigned short fract __fracttauqq (long long 1649 accum A) 1650 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1651 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1652 A) 1653 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1654 accum A) 1655 -- Runtime Function: unsigned short accum __fracttauha (long long 1656 accum A) 1657 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1658 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1659 A) 1660 -- Runtime Function: unsigned long long accum __fracttauta (long long 1661 accum A) 1662 -- Runtime Function: signed char __fracttaqi (long long accum A) 1663 -- Runtime Function: short __fracttahi (long long accum A) 1664 -- Runtime Function: int __fracttasi (long long accum A) 1665 -- Runtime Function: long __fracttadi (long long accum A) 1666 -- Runtime Function: long long __fracttati (long long accum A) 1667 -- Runtime Function: float __fracttasf (long long accum A) 1668 -- Runtime Function: double __fracttadf (long long accum A) 1669 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1670 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1671 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1672 -- Runtime Function: long long fract __fractuqqdq (unsigned short 1673 fract A) 1674 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1675 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1676 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1677 -- Runtime Function: long long accum __fractuqqta (unsigned short 1678 fract A) 1679 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1680 fract A) 1681 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned 1682 short fract A) 1683 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1684 short fract A) 1685 -- Runtime Function: unsigned short accum __fractuqquha (unsigned 1686 short fract A) 1687 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short 1688 fract A) 1689 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1690 fract A) 1691 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1692 short fract A) 1693 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1694 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1695 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1696 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1697 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1698 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1699 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1700 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1701 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1702 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1703 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1704 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1705 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1706 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1707 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1708 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1709 fract A) 1710 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned 1711 fract A) 1712 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1713 fract A) 1714 -- Runtime Function: unsigned short accum __fractuhquha (unsigned 1715 fract A) 1716 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1717 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1718 A) 1719 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1720 fract A) 1721 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1722 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1723 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1724 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1725 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1726 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1727 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1728 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1729 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1730 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1731 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1732 A) 1733 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1734 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1735 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1736 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1737 A) 1738 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned 1739 long fract A) 1740 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long 1741 fract A) 1742 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1743 long fract A) 1744 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1745 fract A) 1746 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1747 A) 1748 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1749 fract A) 1750 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1751 long fract A) 1752 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1753 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1754 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1755 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1756 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1757 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1758 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1759 -- Runtime Function: short fract __fractudqqq (unsigned long long 1760 fract A) 1761 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1762 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1763 A) 1764 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1765 fract A) 1766 -- Runtime Function: short accum __fractudqha (unsigned long long 1767 fract A) 1768 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1769 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1770 A) 1771 -- Runtime Function: long long accum __fractudqta (unsigned long long 1772 fract A) 1773 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned 1774 long long fract A) 1775 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1776 fract A) 1777 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1778 long fract A) 1779 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1780 long fract A) 1781 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1782 fract A) 1783 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1784 long fract A) 1785 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1786 long long fract A) 1787 -- Runtime Function: signed char __fractudqqi (unsigned long long 1788 fract A) 1789 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1790 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1791 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1792 -- Runtime Function: long long __fractudqti (unsigned long long fract 1793 A) 1794 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1795 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1796 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1797 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1798 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1799 -- Runtime Function: long long fract __fractuhadq (unsigned short 1800 accum A) 1801 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1802 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1803 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1804 -- Runtime Function: long long accum __fractuhata (unsigned short 1805 accum A) 1806 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned 1807 short accum A) 1808 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short 1809 accum A) 1810 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1811 accum A) 1812 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1813 short accum A) 1814 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1815 accum A) 1816 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned 1817 short accum A) 1818 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1819 short accum A) 1820 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1821 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1822 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1823 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1824 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1825 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1826 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1827 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1828 -- Runtime Function: fract __fractusahq (unsigned accum A) 1829 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1830 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1831 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1832 -- Runtime Function: accum __fractusasa (unsigned accum A) 1833 -- Runtime Function: long accum __fractusada (unsigned accum A) 1834 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1835 -- Runtime Function: unsigned short fract __fractusauqq (unsigned 1836 accum A) 1837 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1838 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1839 A) 1840 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1841 accum A) 1842 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1843 accum A) 1844 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned 1845 accum A) 1846 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1847 accum A) 1848 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1849 -- Runtime Function: short __fractusahi (unsigned accum A) 1850 -- Runtime Function: int __fractusasi (unsigned accum A) 1851 -- Runtime Function: long __fractusadi (unsigned accum A) 1852 -- Runtime Function: long long __fractusati (unsigned accum A) 1853 -- Runtime Function: float __fractusasf (unsigned accum A) 1854 -- Runtime Function: double __fractusadf (unsigned accum A) 1855 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1856 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1857 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1858 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1859 A) 1860 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1861 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1862 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1863 -- Runtime Function: long long accum __fractudata (unsigned long accum 1864 A) 1865 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1866 accum A) 1867 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1868 A) 1869 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1870 accum A) 1871 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1872 long accum A) 1873 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned 1874 long accum A) 1875 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long 1876 accum A) 1877 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1878 long accum A) 1879 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1880 -- Runtime Function: short __fractudahi (unsigned long accum A) 1881 -- Runtime Function: int __fractudasi (unsigned long accum A) 1882 -- Runtime Function: long __fractudadi (unsigned long accum A) 1883 -- Runtime Function: long long __fractudati (unsigned long accum A) 1884 -- Runtime Function: float __fractudasf (unsigned long accum A) 1885 -- Runtime Function: double __fractudadf (unsigned long accum A) 1886 -- Runtime Function: short fract __fractutaqq (unsigned long long 1887 accum A) 1888 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1889 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1890 A) 1891 -- Runtime Function: long long fract __fractutadq (unsigned long long 1892 accum A) 1893 -- Runtime Function: short accum __fractutaha (unsigned long long 1894 accum A) 1895 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1896 -- Runtime Function: long accum __fractutada (unsigned long long accum 1897 A) 1898 -- Runtime Function: long long accum __fractutata (unsigned long long 1899 accum A) 1900 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1901 long accum A) 1902 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1903 accum A) 1904 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1905 long accum A) 1906 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1907 long long accum A) 1908 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned 1909 long long accum A) 1910 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1911 accum A) 1912 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1913 long accum A) 1914 -- Runtime Function: signed char __fractutaqi (unsigned long long 1915 accum A) 1916 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1917 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1918 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1919 -- Runtime Function: long long __fractutati (unsigned long long accum 1920 A) 1921 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1922 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1923 -- Runtime Function: short fract __fractqiqq (signed char A) 1924 -- Runtime Function: fract __fractqihq (signed char A) 1925 -- Runtime Function: long fract __fractqisq (signed char A) 1926 -- Runtime Function: long long fract __fractqidq (signed char A) 1927 -- Runtime Function: short accum __fractqiha (signed char A) 1928 -- Runtime Function: accum __fractqisa (signed char A) 1929 -- Runtime Function: long accum __fractqida (signed char A) 1930 -- Runtime Function: long long accum __fractqita (signed char A) 1931 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1932 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1933 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1934 -- Runtime Function: unsigned long long fract __fractqiudq (signed 1935 char A) 1936 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1937 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1938 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1939 -- Runtime Function: unsigned long long accum __fractqiuta (signed 1940 char A) 1941 -- Runtime Function: short fract __fracthiqq (short A) 1942 -- Runtime Function: fract __fracthihq (short A) 1943 -- Runtime Function: long fract __fracthisq (short A) 1944 -- Runtime Function: long long fract __fracthidq (short A) 1945 -- Runtime Function: short accum __fracthiha (short A) 1946 -- Runtime Function: accum __fracthisa (short A) 1947 -- Runtime Function: long accum __fracthida (short A) 1948 -- Runtime Function: long long accum __fracthita (short A) 1949 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1950 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1951 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1952 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1953 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1954 -- Runtime Function: unsigned accum __fracthiusa (short A) 1955 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1956 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1957 -- Runtime Function: short fract __fractsiqq (int A) 1958 -- Runtime Function: fract __fractsihq (int A) 1959 -- Runtime Function: long fract __fractsisq (int A) 1960 -- Runtime Function: long long fract __fractsidq (int A) 1961 -- Runtime Function: short accum __fractsiha (int A) 1962 -- Runtime Function: accum __fractsisa (int A) 1963 -- Runtime Function: long accum __fractsida (int A) 1964 -- Runtime Function: long long accum __fractsita (int A) 1965 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1966 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1967 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1968 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1969 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1970 -- Runtime Function: unsigned accum __fractsiusa (int A) 1971 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1972 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1973 -- Runtime Function: short fract __fractdiqq (long A) 1974 -- Runtime Function: fract __fractdihq (long A) 1975 -- Runtime Function: long fract __fractdisq (long A) 1976 -- Runtime Function: long long fract __fractdidq (long A) 1977 -- Runtime Function: short accum __fractdiha (long A) 1978 -- Runtime Function: accum __fractdisa (long A) 1979 -- Runtime Function: long accum __fractdida (long A) 1980 -- Runtime Function: long long accum __fractdita (long A) 1981 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1982 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1983 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1984 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1985 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1986 -- Runtime Function: unsigned accum __fractdiusa (long A) 1987 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1988 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1989 -- Runtime Function: short fract __fracttiqq (long long A) 1990 -- Runtime Function: fract __fracttihq (long long A) 1991 -- Runtime Function: long fract __fracttisq (long long A) 1992 -- Runtime Function: long long fract __fracttidq (long long A) 1993 -- Runtime Function: short accum __fracttiha (long long A) 1994 -- Runtime Function: accum __fracttisa (long long A) 1995 -- Runtime Function: long accum __fracttida (long long A) 1996 -- Runtime Function: long long accum __fracttita (long long A) 1997 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 1998 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 1999 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 2000 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2001 A) 2002 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2003 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2004 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2005 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2006 A) 2007 -- Runtime Function: short fract __fractsfqq (float A) 2008 -- Runtime Function: fract __fractsfhq (float A) 2009 -- Runtime Function: long fract __fractsfsq (float A) 2010 -- Runtime Function: long long fract __fractsfdq (float A) 2011 -- Runtime Function: short accum __fractsfha (float A) 2012 -- Runtime Function: accum __fractsfsa (float A) 2013 -- Runtime Function: long accum __fractsfda (float A) 2014 -- Runtime Function: long long accum __fractsfta (float A) 2015 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2016 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2017 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2018 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2019 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2020 -- Runtime Function: unsigned accum __fractsfusa (float A) 2021 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2022 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2023 -- Runtime Function: short fract __fractdfqq (double A) 2024 -- Runtime Function: fract __fractdfhq (double A) 2025 -- Runtime Function: long fract __fractdfsq (double A) 2026 -- Runtime Function: long long fract __fractdfdq (double A) 2027 -- Runtime Function: short accum __fractdfha (double A) 2028 -- Runtime Function: accum __fractdfsa (double A) 2029 -- Runtime Function: long accum __fractdfda (double A) 2030 -- Runtime Function: long long accum __fractdfta (double A) 2031 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2032 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2033 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2034 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2035 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2036 -- Runtime Function: unsigned accum __fractdfusa (double A) 2037 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2038 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2039 These functions convert from fractional and signed non-fractionals 2040 to fractionals and signed non-fractionals, without saturation. 2041 2042 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2043 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2044 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2045 -- Runtime Function: short accum __satfractqqha (short fract A) 2046 -- Runtime Function: accum __satfractqqsa (short fract A) 2047 -- Runtime Function: long accum __satfractqqda (short fract A) 2048 -- Runtime Function: long long accum __satfractqqta (short fract A) 2049 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2050 A) 2051 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2052 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2053 A) 2054 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2055 fract A) 2056 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2057 A) 2058 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2059 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2060 A) 2061 -- Runtime Function: unsigned long long accum __satfractqquta (short 2062 fract A) 2063 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2064 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2065 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2066 -- Runtime Function: short accum __satfracthqha (fract A) 2067 -- Runtime Function: accum __satfracthqsa (fract A) 2068 -- Runtime Function: long accum __satfracthqda (fract A) 2069 -- Runtime Function: long long accum __satfracthqta (fract A) 2070 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2071 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2072 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2073 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2074 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2075 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2076 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2077 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2078 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2079 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2080 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2081 -- Runtime Function: short accum __satfractsqha (long fract A) 2082 -- Runtime Function: accum __satfractsqsa (long fract A) 2083 -- Runtime Function: long accum __satfractsqda (long fract A) 2084 -- Runtime Function: long long accum __satfractsqta (long fract A) 2085 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2086 A) 2087 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2088 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2089 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2090 fract A) 2091 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2092 A) 2093 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2094 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2095 -- Runtime Function: unsigned long long accum __satfractsquta (long 2096 fract A) 2097 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2098 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2099 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2100 -- Runtime Function: short accum __satfractdqha (long long fract A) 2101 -- Runtime Function: accum __satfractdqsa (long long fract A) 2102 -- Runtime Function: long accum __satfractdqda (long long fract A) 2103 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2104 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2105 fract A) 2106 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2107 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2108 fract A) 2109 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2110 long fract A) 2111 -- Runtime Function: unsigned short accum __satfractdquha (long long 2112 fract A) 2113 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2114 -- Runtime Function: unsigned long accum __satfractdquda (long long 2115 fract A) 2116 -- Runtime Function: unsigned long long accum __satfractdquta (long 2117 long fract A) 2118 -- Runtime Function: short fract __satfracthaqq (short accum A) 2119 -- Runtime Function: fract __satfracthahq (short accum A) 2120 -- Runtime Function: long fract __satfracthasq (short accum A) 2121 -- Runtime Function: long long fract __satfracthadq (short accum A) 2122 -- Runtime Function: accum __satfracthasa2 (short accum A) 2123 -- Runtime Function: long accum __satfracthada2 (short accum A) 2124 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2125 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2126 A) 2127 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2128 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2129 A) 2130 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2131 accum A) 2132 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2133 A) 2134 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2135 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2136 A) 2137 -- Runtime Function: unsigned long long accum __satfracthauta (short 2138 accum A) 2139 -- Runtime Function: short fract __satfractsaqq (accum A) 2140 -- Runtime Function: fract __satfractsahq (accum A) 2141 -- Runtime Function: long fract __satfractsasq (accum A) 2142 -- Runtime Function: long long fract __satfractsadq (accum A) 2143 -- Runtime Function: short accum __satfractsaha2 (accum A) 2144 -- Runtime Function: long accum __satfractsada2 (accum A) 2145 -- Runtime Function: long long accum __satfractsata2 (accum A) 2146 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2147 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2148 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2149 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2150 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2151 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2152 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2153 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2154 -- Runtime Function: short fract __satfractdaqq (long accum A) 2155 -- Runtime Function: fract __satfractdahq (long accum A) 2156 -- Runtime Function: long fract __satfractdasq (long accum A) 2157 -- Runtime Function: long long fract __satfractdadq (long accum A) 2158 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2159 -- Runtime Function: accum __satfractdasa2 (long accum A) 2160 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2161 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2162 A) 2163 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2164 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2165 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2166 accum A) 2167 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2168 A) 2169 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2170 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2171 -- Runtime Function: unsigned long long accum __satfractdauta (long 2172 accum A) 2173 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2174 -- Runtime Function: fract __satfracttahq (long long accum A) 2175 -- Runtime Function: long fract __satfracttasq (long long accum A) 2176 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2177 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2178 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2179 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2180 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2181 accum A) 2182 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2183 -- Runtime Function: unsigned long fract __satfracttausq (long long 2184 accum A) 2185 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2186 long accum A) 2187 -- Runtime Function: unsigned short accum __satfracttauha (long long 2188 accum A) 2189 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2190 -- Runtime Function: unsigned long accum __satfracttauda (long long 2191 accum A) 2192 -- Runtime Function: unsigned long long accum __satfracttauta (long 2193 long accum A) 2194 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2195 A) 2196 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2197 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2198 A) 2199 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2200 fract A) 2201 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2202 A) 2203 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2204 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2205 A) 2206 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2207 fract A) 2208 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2209 fract A) 2210 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2211 short fract A) 2212 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2213 (unsigned short fract A) 2214 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2215 short fract A) 2216 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2217 fract A) 2218 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2219 short fract A) 2220 -- Runtime Function: unsigned long long accum __satfractuqquta 2221 (unsigned short fract A) 2222 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2223 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2224 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2225 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2226 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2227 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2228 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2229 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2230 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2231 fract A) 2232 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2233 fract A) 2234 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2235 (unsigned fract A) 2236 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2237 fract A) 2238 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2239 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2240 fract A) 2241 -- Runtime Function: unsigned long long accum __satfractuhquta 2242 (unsigned fract A) 2243 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2244 A) 2245 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2246 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2247 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2248 fract A) 2249 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2250 A) 2251 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2252 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2253 -- Runtime Function: long long accum __satfractusqta (unsigned long 2254 fract A) 2255 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2256 long fract A) 2257 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2258 fract A) 2259 -- Runtime Function: unsigned long long fract __satfractusqudq2 2260 (unsigned long fract A) 2261 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2262 long fract A) 2263 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2264 fract A) 2265 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2266 long fract A) 2267 -- Runtime Function: unsigned long long accum __satfractusquta 2268 (unsigned long fract A) 2269 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2270 fract A) 2271 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2272 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2273 fract A) 2274 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2275 long fract A) 2276 -- Runtime Function: short accum __satfractudqha (unsigned long long 2277 fract A) 2278 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2279 -- Runtime Function: long accum __satfractudqda (unsigned long long 2280 fract A) 2281 -- Runtime Function: long long accum __satfractudqta (unsigned long 2282 long fract A) 2283 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2284 long long fract A) 2285 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2286 long fract A) 2287 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2288 long long fract A) 2289 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2290 long long fract A) 2291 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2292 long fract A) 2293 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2294 long long fract A) 2295 -- Runtime Function: unsigned long long accum __satfractudquta 2296 (unsigned long long fract A) 2297 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2298 A) 2299 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2300 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2301 A) 2302 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2303 accum A) 2304 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2305 A) 2306 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2307 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2308 A) 2309 -- Runtime Function: long long accum __satfractuhata (unsigned short 2310 accum A) 2311 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2312 short accum A) 2313 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2314 accum A) 2315 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2316 short accum A) 2317 -- Runtime Function: unsigned long long fract __satfractuhaudq 2318 (unsigned short accum A) 2319 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2320 accum A) 2321 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2322 short accum A) 2323 -- Runtime Function: unsigned long long accum __satfractuhauta2 2324 (unsigned short accum A) 2325 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2326 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2327 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2328 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2329 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2330 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2331 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2332 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2333 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2334 accum A) 2335 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2336 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2337 accum A) 2338 -- Runtime Function: unsigned long long fract __satfractusaudq 2339 (unsigned accum A) 2340 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2341 accum A) 2342 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2343 accum A) 2344 -- Runtime Function: unsigned long long accum __satfractusauta2 2345 (unsigned accum A) 2346 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2347 A) 2348 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2349 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2350 -- Runtime Function: long long fract __satfractudadq (unsigned long 2351 accum A) 2352 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2353 A) 2354 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2355 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2356 -- Runtime Function: long long accum __satfractudata (unsigned long 2357 accum A) 2358 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2359 long accum A) 2360 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2361 accum A) 2362 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2363 long accum A) 2364 -- Runtime Function: unsigned long long fract __satfractudaudq 2365 (unsigned long accum A) 2366 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2367 long accum A) 2368 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2369 accum A) 2370 -- Runtime Function: unsigned long long accum __satfractudauta2 2371 (unsigned long accum A) 2372 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2373 accum A) 2374 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2375 -- Runtime Function: long fract __satfractutasq (unsigned long long 2376 accum A) 2377 -- Runtime Function: long long fract __satfractutadq (unsigned long 2378 long accum A) 2379 -- Runtime Function: short accum __satfractutaha (unsigned long long 2380 accum A) 2381 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2382 -- Runtime Function: long accum __satfractutada (unsigned long long 2383 accum A) 2384 -- Runtime Function: long long accum __satfractutata (unsigned long 2385 long accum A) 2386 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2387 long long accum A) 2388 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2389 long accum A) 2390 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2391 long long accum A) 2392 -- Runtime Function: unsigned long long fract __satfractutaudq 2393 (unsigned long long accum A) 2394 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2395 long long accum A) 2396 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2397 long accum A) 2398 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2399 long long accum A) 2400 -- Runtime Function: short fract __satfractqiqq (signed char A) 2401 -- Runtime Function: fract __satfractqihq (signed char A) 2402 -- Runtime Function: long fract __satfractqisq (signed char A) 2403 -- Runtime Function: long long fract __satfractqidq (signed char A) 2404 -- Runtime Function: short accum __satfractqiha (signed char A) 2405 -- Runtime Function: accum __satfractqisa (signed char A) 2406 -- Runtime Function: long accum __satfractqida (signed char A) 2407 -- Runtime Function: long long accum __satfractqita (signed char A) 2408 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2409 A) 2410 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2411 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2412 A) 2413 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2414 char A) 2415 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2416 A) 2417 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2418 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2419 A) 2420 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2421 char A) 2422 -- Runtime Function: short fract __satfracthiqq (short A) 2423 -- Runtime Function: fract __satfracthihq (short A) 2424 -- Runtime Function: long fract __satfracthisq (short A) 2425 -- Runtime Function: long long fract __satfracthidq (short A) 2426 -- Runtime Function: short accum __satfracthiha (short A) 2427 -- Runtime Function: accum __satfracthisa (short A) 2428 -- Runtime Function: long accum __satfracthida (short A) 2429 -- Runtime Function: long long accum __satfracthita (short A) 2430 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2431 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2432 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2433 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2434 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2435 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2436 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2437 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2438 -- Runtime Function: short fract __satfractsiqq (int A) 2439 -- Runtime Function: fract __satfractsihq (int A) 2440 -- Runtime Function: long fract __satfractsisq (int A) 2441 -- Runtime Function: long long fract __satfractsidq (int A) 2442 -- Runtime Function: short accum __satfractsiha (int A) 2443 -- Runtime Function: accum __satfractsisa (int A) 2444 -- Runtime Function: long accum __satfractsida (int A) 2445 -- Runtime Function: long long accum __satfractsita (int A) 2446 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2447 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2448 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2449 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2450 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2451 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2452 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2453 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2454 -- Runtime Function: short fract __satfractdiqq (long A) 2455 -- Runtime Function: fract __satfractdihq (long A) 2456 -- Runtime Function: long fract __satfractdisq (long A) 2457 -- Runtime Function: long long fract __satfractdidq (long A) 2458 -- Runtime Function: short accum __satfractdiha (long A) 2459 -- Runtime Function: accum __satfractdisa (long A) 2460 -- Runtime Function: long accum __satfractdida (long A) 2461 -- Runtime Function: long long accum __satfractdita (long A) 2462 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2463 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2464 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2465 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2466 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2467 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2468 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2469 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2470 -- Runtime Function: short fract __satfracttiqq (long long A) 2471 -- Runtime Function: fract __satfracttihq (long long A) 2472 -- Runtime Function: long fract __satfracttisq (long long A) 2473 -- Runtime Function: long long fract __satfracttidq (long long A) 2474 -- Runtime Function: short accum __satfracttiha (long long A) 2475 -- Runtime Function: accum __satfracttisa (long long A) 2476 -- Runtime Function: long accum __satfracttida (long long A) 2477 -- Runtime Function: long long accum __satfracttita (long long A) 2478 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2479 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2480 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2481 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2482 long A) 2483 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2484 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2485 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2486 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2487 long A) 2488 -- Runtime Function: short fract __satfractsfqq (float A) 2489 -- Runtime Function: fract __satfractsfhq (float A) 2490 -- Runtime Function: long fract __satfractsfsq (float A) 2491 -- Runtime Function: long long fract __satfractsfdq (float A) 2492 -- Runtime Function: short accum __satfractsfha (float A) 2493 -- Runtime Function: accum __satfractsfsa (float A) 2494 -- Runtime Function: long accum __satfractsfda (float A) 2495 -- Runtime Function: long long accum __satfractsfta (float A) 2496 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2497 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2498 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2499 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2500 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2501 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2502 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2503 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2504 -- Runtime Function: short fract __satfractdfqq (double A) 2505 -- Runtime Function: fract __satfractdfhq (double A) 2506 -- Runtime Function: long fract __satfractdfsq (double A) 2507 -- Runtime Function: long long fract __satfractdfdq (double A) 2508 -- Runtime Function: short accum __satfractdfha (double A) 2509 -- Runtime Function: accum __satfractdfsa (double A) 2510 -- Runtime Function: long accum __satfractdfda (double A) 2511 -- Runtime Function: long long accum __satfractdfta (double A) 2512 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2513 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2514 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2515 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2516 A) 2517 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2518 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2519 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2520 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2521 A) 2522 The functions convert from fractional and signed non-fractionals to 2523 fractionals, with saturation. 2524 2525 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2526 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2527 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2528 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2529 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2530 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2531 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2532 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2533 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2534 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2535 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2536 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2537 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2538 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2539 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2540 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2541 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2542 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2543 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2544 -- Runtime Function: unsigned long long __fractunsdqti (long long 2545 fract A) 2546 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2547 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2548 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2549 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2550 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2551 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2552 -- Runtime Function: unsigned short __fractunssahi (accum A) 2553 -- Runtime Function: unsigned int __fractunssasi (accum A) 2554 -- Runtime Function: unsigned long __fractunssadi (accum A) 2555 -- Runtime Function: unsigned long long __fractunssati (accum A) 2556 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2557 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2558 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2559 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2560 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2561 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2562 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2563 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2564 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2565 -- Runtime Function: unsigned long long __fractunstati (long long 2566 accum A) 2567 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2568 fract A) 2569 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2570 fract A) 2571 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short 2572 fract A) 2573 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2574 fract A) 2575 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned 2576 short fract A) 2577 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2578 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2579 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2580 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2581 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned 2582 fract A) 2583 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long 2584 fract A) 2585 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2586 fract A) 2587 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2588 A) 2589 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long 2590 fract A) 2591 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2592 fract A) 2593 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2594 fract A) 2595 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long 2596 long fract A) 2597 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2598 fract A) 2599 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2600 fract A) 2601 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2602 long fract A) 2603 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2604 accum A) 2605 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2606 accum A) 2607 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short 2608 accum A) 2609 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2610 accum A) 2611 -- Runtime Function: unsigned long long __fractunsuhati (unsigned 2612 short accum A) 2613 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2614 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2615 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2616 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2617 -- Runtime Function: unsigned long long __fractunsusati (unsigned 2618 accum A) 2619 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long 2620 accum A) 2621 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2622 accum A) 2623 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2624 A) 2625 -- Runtime Function: unsigned long __fractunsudadi (unsigned long 2626 accum A) 2627 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2628 accum A) 2629 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2630 accum A) 2631 -- Runtime Function: unsigned short __fractunsutahi (unsigned long 2632 long accum A) 2633 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2634 accum A) 2635 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2636 accum A) 2637 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2638 long accum A) 2639 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2640 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2641 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2642 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2643 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2644 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2645 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2646 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2647 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2648 char A) 2649 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2650 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned 2651 char A) 2652 -- Runtime Function: unsigned long long fract __fractunsqiudq 2653 (unsigned char A) 2654 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2655 char A) 2656 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2657 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned 2658 char A) 2659 -- Runtime Function: unsigned long long accum __fractunsqiuta 2660 (unsigned char A) 2661 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2662 -- Runtime Function: fract __fractunshihq (unsigned short A) 2663 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2664 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2665 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2666 -- Runtime Function: accum __fractunshisa (unsigned short A) 2667 -- Runtime Function: long accum __fractunshida (unsigned short A) 2668 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2669 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2670 short A) 2671 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2672 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2673 short A) 2674 -- Runtime Function: unsigned long long fract __fractunshiudq 2675 (unsigned short A) 2676 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2677 short A) 2678 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2679 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2680 short A) 2681 -- Runtime Function: unsigned long long accum __fractunshiuta 2682 (unsigned short A) 2683 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2684 -- Runtime Function: fract __fractunssihq (unsigned int A) 2685 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2686 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2687 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2688 -- Runtime Function: accum __fractunssisa (unsigned int A) 2689 -- Runtime Function: long accum __fractunssida (unsigned int A) 2690 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2691 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned 2692 int A) 2693 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2694 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2695 A) 2696 -- Runtime Function: unsigned long long fract __fractunssiudq 2697 (unsigned int A) 2698 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned 2699 int A) 2700 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2701 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2702 A) 2703 -- Runtime Function: unsigned long long accum __fractunssiuta 2704 (unsigned int A) 2705 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2706 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2707 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2708 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2709 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2710 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2711 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2712 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2713 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2714 long A) 2715 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2716 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned 2717 long A) 2718 -- Runtime Function: unsigned long long fract __fractunsdiudq 2719 (unsigned long A) 2720 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2721 long A) 2722 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2723 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned 2724 long A) 2725 -- Runtime Function: unsigned long long accum __fractunsdiuta 2726 (unsigned long A) 2727 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2728 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2729 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2730 -- Runtime Function: long long fract __fractunstidq (unsigned long 2731 long A) 2732 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2733 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2734 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2735 -- Runtime Function: long long accum __fractunstita (unsigned long 2736 long A) 2737 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2738 long long A) 2739 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long 2740 long A) 2741 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned 2742 long long A) 2743 -- Runtime Function: unsigned long long fract __fractunstiudq 2744 (unsigned long long A) 2745 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2746 long long A) 2747 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long 2748 long A) 2749 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned 2750 long long A) 2751 -- Runtime Function: unsigned long long accum __fractunstiuta 2752 (unsigned long long A) 2753 These functions convert from fractionals to unsigned 2754 non-fractionals; and from unsigned non-fractionals to fractionals, 2755 without saturation. 2756 2757 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2758 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2759 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2760 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2761 A) 2762 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2763 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2764 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2765 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2766 A) 2767 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2768 char A) 2769 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2770 A) 2771 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2772 char A) 2773 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2774 (unsigned char A) 2775 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2776 char A) 2777 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2778 A) 2779 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2780 char A) 2781 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2782 (unsigned char A) 2783 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2784 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2785 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2786 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2787 A) 2788 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2789 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2790 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2791 -- Runtime Function: long long accum __satfractunshita (unsigned short 2792 A) 2793 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2794 short A) 2795 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2796 A) 2797 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2798 short A) 2799 -- Runtime Function: unsigned long long fract __satfractunshiudq 2800 (unsigned short A) 2801 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2802 short A) 2803 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2804 A) 2805 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2806 short A) 2807 -- Runtime Function: unsigned long long accum __satfractunshiuta 2808 (unsigned short A) 2809 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2810 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2811 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2812 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2813 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2814 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2815 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2816 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2817 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2818 int A) 2819 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2820 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2821 int A) 2822 -- Runtime Function: unsigned long long fract __satfractunssiudq 2823 (unsigned int A) 2824 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2825 int A) 2826 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2827 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2828 int A) 2829 -- Runtime Function: unsigned long long accum __satfractunssiuta 2830 (unsigned int A) 2831 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2832 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2833 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2834 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2835 A) 2836 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2837 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2838 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2839 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2840 A) 2841 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2842 long A) 2843 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2844 A) 2845 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2846 long A) 2847 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2848 (unsigned long A) 2849 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2850 long A) 2851 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2852 A) 2853 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2854 long A) 2855 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2856 (unsigned long A) 2857 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2858 A) 2859 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2860 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2861 A) 2862 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2863 long A) 2864 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2865 A) 2866 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2867 -- Runtime Function: long accum __satfractunstida (unsigned long long 2868 A) 2869 -- Runtime Function: long long accum __satfractunstita (unsigned long 2870 long A) 2871 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2872 long long A) 2873 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2874 long A) 2875 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2876 long long A) 2877 -- Runtime Function: unsigned long long fract __satfractunstiudq 2878 (unsigned long long A) 2879 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2880 long long A) 2881 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2882 long A) 2883 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2884 long long A) 2885 -- Runtime Function: unsigned long long accum __satfractunstiuta 2886 (unsigned long long A) 2887 These functions convert from unsigned non-fractionals to 2888 fractionals, with saturation. 2889 2890 2891File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2892 28934.5 Language-independent routines for exception handling 2894======================================================== 2895 2896document me! 2897 2898 _Unwind_DeleteException 2899 _Unwind_Find_FDE 2900 _Unwind_ForcedUnwind 2901 _Unwind_GetGR 2902 _Unwind_GetIP 2903 _Unwind_GetLanguageSpecificData 2904 _Unwind_GetRegionStart 2905 _Unwind_GetTextRelBase 2906 _Unwind_GetDataRelBase 2907 _Unwind_RaiseException 2908 _Unwind_Resume 2909 _Unwind_SetGR 2910 _Unwind_SetIP 2911 _Unwind_FindEnclosingFunction 2912 _Unwind_SjLj_Register 2913 _Unwind_SjLj_Unregister 2914 _Unwind_SjLj_RaiseException 2915 _Unwind_SjLj_ForcedUnwind 2916 _Unwind_SjLj_Resume 2917 __deregister_frame 2918 __deregister_frame_info 2919 __deregister_frame_info_bases 2920 __register_frame 2921 __register_frame_info 2922 __register_frame_info_bases 2923 __register_frame_info_table 2924 __register_frame_info_table_bases 2925 __register_frame_table 2926 2927 2928File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2929 29304.6 Miscellaneous runtime library routines 2931========================================== 2932 29334.6.1 Cache control functions 2934----------------------------- 2935 2936 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2937 This function clears the instruction cache between BEG and END. 2938 29394.6.2 Split stack functions and variables 2940----------------------------------------- 2941 2942 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2943 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2944 **INITIAL_SP) 2945 When using `-fsplit-stack', this call may be used to iterate over 2946 the stack segments. It may be called like this: 2947 void *next_segment = NULL; 2948 void *next_sp = NULL; 2949 void *initial_sp = NULL; 2950 void *stack; 2951 size_t stack_size; 2952 while ((stack = __splitstack_find (next_segment, next_sp, 2953 &stack_size, &next_segment, 2954 &next_sp, &initial_sp)) 2955 != NULL) 2956 { 2957 /* Stack segment starts at stack and is 2958 stack_size bytes long. */ 2959 } 2960 2961 There is no way to iterate over the stack segments of a different 2962 thread. However, what is permitted is for one thread to call this 2963 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2964 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2965 one way or another. A different thread may run the subsequent 2966 `__splitstack_find' iterations. Of course, this will only work if 2967 the first thread is suspended while the second thread is calling 2968 `__splitstack_find'. If not, the second thread could be looking 2969 at the stack while it is changing, and anything could happen. 2970 2971 -- Variable: __morestack_segments 2972 -- Variable: __morestack_current_segment 2973 -- Variable: __morestack_initial_sp 2974 Internal variables used by the `-fsplit-stack' implementation. 2975 2976 2977File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2978 29795 Language Front Ends in GCC 2980**************************** 2981 2982The interface to front ends for languages in GCC, and in particular the 2983`tree' structure (*note GENERIC::), was initially designed for C, and 2984many aspects of it are still somewhat biased towards C and C-like 2985languages. It is, however, reasonably well suited to other procedural 2986languages, and front ends for many such languages have been written for 2987GCC. 2988 2989 Writing a compiler as a front end for GCC, rather than compiling 2990directly to assembler or generating C code which is then compiled by 2991GCC, has several advantages: 2992 2993 * GCC front ends benefit from the support for many different target 2994 machines already present in GCC. 2995 2996 * GCC front ends benefit from all the optimizations in GCC. Some of 2997 these, such as alias analysis, may work better when GCC is 2998 compiling directly from source code then when it is compiling from 2999 generated C code. 3000 3001 * Better debugging information is generated when compiling directly 3002 from source code than when going via intermediate generated C code. 3003 3004 Because of the advantages of writing a compiler as a GCC front end, 3005GCC front ends have also been created for languages very different from 3006those for which GCC was designed, such as the declarative 3007logic/functional language Mercury. For these reasons, it may also be 3008useful to implement compilers created for specialized purposes (for 3009example, as part of a research project) as GCC front ends. 3010 3011 3012File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3013 30146 Source Tree Structure and Build System 3015**************************************** 3016 3017This chapter describes the structure of the GCC source tree, and how 3018GCC is built. The user documentation for building and installing GCC 3019is in a separate manual (`http://gcc.gnu.org/install/'), with which it 3020is presumed that you are familiar. 3021 3022* Menu: 3023 3024* Configure Terms:: Configuration terminology and history. 3025* Top Level:: The top level source directory. 3026* gcc Directory:: The `gcc' subdirectory. 3027 3028 3029File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3030 30316.1 Configure Terms and History 3032=============================== 3033 3034The configure and build process has a long and colorful history, and can 3035be confusing to anyone who doesn't know why things are the way they are. 3036While there are other documents which describe the configuration process 3037in detail, here are a few things that everyone working on GCC should 3038know. 3039 3040 There are three system names that the build knows about: the machine 3041you are building on ("build"), the machine that you are building for 3042("host"), and the machine that GCC will produce code for ("target"). 3043When you configure GCC, you specify these with `--build=', `--host=', 3044and `--target='. 3045 3046 Specifying the host without specifying the build should be avoided, as 3047`configure' may (and once did) assume that the host you specify is also 3048the build, which may not be true. 3049 3050 If build, host, and target are all the same, this is called a 3051"native". If build and host are the same but target is different, this 3052is called a "cross". If build, host, and target are all different this 3053is called a "canadian" (for obscure reasons dealing with Canada's 3054political party and the background of the person working on the build 3055at that time). If host and target are the same, but build is 3056different, you are using a cross-compiler to build a native for a 3057different system. Some people call this a "host-x-host", "crossed 3058native", or "cross-built native". If build and target are the same, 3059but host is different, you are using a cross compiler to build a cross 3060compiler that produces code for the machine you're building on. This 3061is rare, so there is no common way of describing it. There is a 3062proposal to call this a "crossback". 3063 3064 If build and host are the same, the GCC you are building will also be 3065used to build the target libraries (like `libstdc++'). If build and 3066host are different, you must have already built and installed a cross 3067compiler that will be used to build the target libraries (if you 3068configured with `--target=foo-bar', this compiler will be called 3069`foo-bar-gcc'). 3070 3071 In the case of target libraries, the machine you're building for is the 3072machine you specified with `--target'. So, build is the machine you're 3073building on (no change there), host is the machine you're building for 3074(the target libraries are built for the target, so host is the target 3075you specified), and target doesn't apply (because you're not building a 3076compiler, you're building libraries). The configure/make process will 3077adjust these variables as needed. It also sets `$with_cross_host' to 3078the original `--host' value in case you need it. 3079 3080 The `libiberty' support library is built up to three times: once for 3081the host, once for the target (even if they are the same), and once for 3082the build if build and host are different. This allows it to be used 3083by all programs which are generated in the course of the build process. 3084 3085 3086File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3087 30886.2 Top Level Source Directory 3089============================== 3090 3091The top level source directory in a GCC distribution contains several 3092files and directories that are shared with other software distributions 3093such as that of GNU Binutils. It also contains several subdirectories 3094that contain parts of GCC and its runtime libraries: 3095 3096`boehm-gc' 3097 The Boehm conservative garbage collector, used as part of the Java 3098 runtime library. 3099 3100`config' 3101 Autoconf macros and Makefile fragments used throughout the tree. 3102 3103`contrib' 3104 Contributed scripts that may be found useful in conjunction with 3105 GCC. One of these, `contrib/texi2pod.pl', is used to generate man 3106 pages from Texinfo manuals as part of the GCC build process. 3107 3108`fixincludes' 3109 The support for fixing system headers to work with GCC. See 3110 `fixincludes/README' for more information. The headers fixed by 3111 this mechanism are installed in `LIBSUBDIR/include-fixed'. Along 3112 with those headers, `README-fixinc' is also installed, as 3113 `LIBSUBDIR/include-fixed/README'. 3114 3115`gcc' 3116 The main sources of GCC itself (except for runtime libraries), 3117 including optimizers, support for different target architectures, 3118 language front ends, and testsuites. *Note The `gcc' 3119 Subdirectory: gcc Directory, for details. 3120 3121`gnattools' 3122 Support tools for GNAT. 3123 3124`include' 3125 Headers for the `libiberty' library. 3126 3127`intl' 3128 GNU `libintl', from GNU `gettext', for systems which do not 3129 include it in `libc'. 3130 3131`libada' 3132 The Ada runtime library. 3133 3134`libatomic' 3135 The runtime support library for atomic operations (e.g. for 3136 `__sync' and `__atomic'). 3137 3138`libcpp' 3139 The C preprocessor library. 3140 3141`libdecnumber' 3142 The Decimal Float support library. 3143 3144`libffi' 3145 The `libffi' library, used as part of the Java runtime library. 3146 3147`libgcc' 3148 The GCC runtime library. 3149 3150`libgfortran' 3151 The Fortran runtime library. 3152 3153`libgo' 3154 The Go runtime library. The bulk of this library is mirrored from 3155 the master Go repository (http://code.google.com/p/go/). 3156 3157`libgomp' 3158 The GNU OpenMP runtime library. 3159 3160`libiberty' 3161 The `libiberty' library, used for portability and for some 3162 generally useful data structures and algorithms. *Note 3163 Introduction: (libiberty)Top, for more information about this 3164 library. 3165 3166`libitm' 3167 The runtime support library for transactional memory. 3168 3169`libjava' 3170 The Java runtime library. 3171 3172`libmudflap' 3173 The `libmudflap' library, used for instrumenting pointer and array 3174 dereferencing operations. 3175 3176`libobjc' 3177 The Objective-C and Objective-C++ runtime library. 3178 3179`libquadmath' 3180 The runtime support library for quad-precision math operations. 3181 3182`libssp' 3183 The Stack protector runtime library. 3184 3185`libstdc++-v3' 3186 The C++ runtime library. 3187 3188`lto-plugin' 3189 Plugin used by `gold' if link-time optimizations are enabled. 3190 3191`maintainer-scripts' 3192 Scripts used by the `gccadmin' account on `gcc.gnu.org'. 3193 3194`zlib' 3195 The `zlib' compression library, used by the Java front end, as 3196 part of the Java runtime library, and for compressing and 3197 uncompressing GCC's intermediate language in LTO object files. 3198 3199 The build system in the top level directory, including how recursion 3200into subdirectories works and how building runtime libraries for 3201multilibs is handled, is documented in a separate manual, included with 3202GNU Binutils. *Note GNU configure and build system: (configure)Top, 3203for details. 3204 3205 3206File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3207 32086.3 The `gcc' Subdirectory 3209========================== 3210 3211The `gcc' directory contains many files that are part of the C sources 3212of GCC, other files used as part of the configuration and build 3213process, and subdirectories including documentation and a testsuite. 3214The files that are sources of GCC are documented in a separate chapter. 3215*Note Passes and Files of the Compiler: Passes. 3216 3217* Menu: 3218 3219* Subdirectories:: Subdirectories of `gcc'. 3220* Configuration:: The configuration process, and the files it uses. 3221* Build:: The build system in the `gcc' directory. 3222* Makefile:: Targets in `gcc/Makefile'. 3223* Library Files:: Library source files and headers under `gcc/'. 3224* Headers:: Headers installed by GCC. 3225* Documentation:: Building documentation in GCC. 3226* Front End:: Anatomy of a language front end. 3227* Back End:: Anatomy of a target back end. 3228 3229 3230File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3231 32326.3.1 Subdirectories of `gcc' 3233----------------------------- 3234 3235The `gcc' directory contains the following subdirectories: 3236 3237`LANGUAGE' 3238 Subdirectories for various languages. Directories containing a 3239 file `config-lang.in' are language subdirectories. The contents of 3240 the subdirectories `c' (for C), `cp' (for C++), `objc' (for 3241 Objective-C), `objcp' (for Objective-C++), and `lto' (for LTO) are 3242 documented in this manual (*note Passes and Files of the Compiler: 3243 Passes.); those for other languages are not. *Note Anatomy of a 3244 Language Front End: Front End, for details of the files in these 3245 directories. 3246 3247`common' 3248 Source files shared between the compiler drivers (such as `gcc') 3249 and the compilers proper (such as `cc1'). If an architecture 3250 defines target hooks shared between those places, it also has a 3251 subdirectory in `common/config'. *Note Target Structure::. 3252 3253`config' 3254 Configuration files for supported architectures and operating 3255 systems. *Note Anatomy of a Target Back End: Back End, for 3256 details of the files in this directory. 3257 3258`doc' 3259 Texinfo documentation for GCC, together with automatically 3260 generated man pages and support for converting the installation 3261 manual to HTML. *Note Documentation::. 3262 3263`ginclude' 3264 System headers installed by GCC, mainly those required by the C 3265 standard of freestanding implementations. *Note Headers Installed 3266 by GCC: Headers, for details of when these and other headers are 3267 installed. 3268 3269`po' 3270 Message catalogs with translations of messages produced by GCC into 3271 various languages, `LANGUAGE.po'. This directory also contains 3272 `gcc.pot', the template for these message catalogues, `exgettext', 3273 a wrapper around `gettext' to extract the messages from the GCC 3274 sources and create `gcc.pot', which is run by `make gcc.pot', and 3275 `EXCLUDES', a list of files from which messages should not be 3276 extracted. 3277 3278`testsuite' 3279 The GCC testsuites (except for those for runtime libraries). 3280 *Note Testsuites::. 3281 3282 3283File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3284 32856.3.2 Configuration in the `gcc' Directory 3286------------------------------------------ 3287 3288The `gcc' directory is configured with an Autoconf-generated script 3289`configure'. The `configure' script is generated from `configure.ac' 3290and `aclocal.m4'. From the files `configure.ac' and `acconfig.h', 3291Autoheader generates the file `config.in'. The file `cstamp-h.in' is 3292used as a timestamp. 3293 3294* Menu: 3295 3296* Config Fragments:: Scripts used by `configure'. 3297* System Config:: The `config.build', `config.host', and 3298 `config.gcc' files. 3299* Configuration Files:: Files created by running `configure'. 3300 3301 3302File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3303 33046.3.2.1 Scripts Used by `configure' 3305................................... 3306 3307`configure' uses some other scripts to help in its work: 3308 3309 * The standard GNU `config.sub' and `config.guess' files, kept in 3310 the top level directory, are used. 3311 3312 * The file `config.gcc' is used to handle configuration specific to 3313 the particular target machine. The file `config.build' is used to 3314 handle configuration specific to the particular build machine. 3315 The file `config.host' is used to handle configuration specific to 3316 the particular host machine. (In general, these should only be 3317 used for features that cannot reasonably be tested in Autoconf 3318 feature tests.) *Note The `config.build'; `config.host'; and 3319 `config.gcc' Files: System Config, for details of the contents of 3320 these files. 3321 3322 * Each language subdirectory has a file `LANGUAGE/config-lang.in' 3323 that is used for front-end-specific configuration. *Note The 3324 Front End `config-lang.in' File: Front End Config, for details of 3325 this file. 3326 3327 * A helper script `configure.frag' is used as part of creating the 3328 output of `configure'. 3329 3330 3331File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3332 33336.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files 3334................................................................. 3335 3336The `config.build' file contains specific rules for particular systems 3337which GCC is built on. This should be used as rarely as possible, as 3338the behavior of the build system can always be detected by autoconf. 3339 3340 The `config.host' file contains specific rules for particular systems 3341which GCC will run on. This is rarely needed. 3342 3343 The `config.gcc' file contains specific rules for particular systems 3344which GCC will generate code for. This is usually needed. 3345 3346 Each file has a list of the shell variables it sets, with 3347descriptions, at the top of the file. 3348 3349 FIXME: document the contents of these files, and what variables should 3350be set to control build, host and target configuration. 3351 3352 3353File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3354 33556.3.2.3 Files Created by `configure' 3356.................................... 3357 3358Here we spell out what files will be set up by `configure' in the `gcc' 3359directory. Some other files are created as temporary files in the 3360configuration process, and are not used in the subsequent build; these 3361are not documented. 3362 3363 * `Makefile' is constructed from `Makefile.in', together with the 3364 host and target fragments (*note Makefile Fragments: Fragments.) 3365 `t-TARGET' and `x-HOST' from `config', if any, and language 3366 Makefile fragments `LANGUAGE/Make-lang.in'. 3367 3368 * `auto-host.h' contains information about the host machine 3369 determined by `configure'. If the host machine is different from 3370 the build machine, then `auto-build.h' is also created, containing 3371 such information about the build machine. 3372 3373 * `config.status' is a script that may be run to recreate the 3374 current configuration. 3375 3376 * `configargs.h' is a header containing details of the arguments 3377 passed to `configure' to configure GCC, and of the thread model 3378 used. 3379 3380 * `cstamp-h' is used as a timestamp. 3381 3382 * If a language `config-lang.in' file (*note The Front End 3383 `config-lang.in' File: Front End Config.) sets `outputs', then the 3384 files listed in `outputs' there are also generated. 3385 3386 The following configuration headers are created from the Makefile, 3387using `mkconfig.sh', rather than directly by `configure'. `config.h', 3388`bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if 3389any, appropriate to the host, build and target machines respectively, 3390the configuration headers for the target, and some definitions; for the 3391host and build machines, these include the autoconfigured headers 3392generated by `configure'. The other configuration headers are 3393determined by `config.gcc'. They also contain the typedefs for `rtx', 3394`rtvec' and `tree'. 3395 3396 * `config.h', for use in programs that run on the host machine. 3397 3398 * `bconfig.h', for use in programs that run on the build machine. 3399 3400 * `tconfig.h', for use in programs and libraries for the target 3401 machine. 3402 3403 * `tm_p.h', which includes the header `MACHINE-protos.h' that 3404 contains prototypes for functions in the target `MACHINE.c' file. 3405 The header `MACHINE-protos.h' can include prototypes of functions 3406 that use rtl and tree data structures inside appropriate `#ifdef 3407 RTX_CODE' and `#ifdef TREE_CODE' conditional code segements. The 3408 `MACHINE-protos.h' is included after the `rtl.h' and/or `tree.h' 3409 would have been included. The `tm_p.h' also includes the header 3410 `tm-preds.h' which is generated by `genpreds' program during the 3411 build to define the declarations and inline functions for the 3412 predicate functions. 3413 3414 3415File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3416 34176.3.3 Build System in the `gcc' Directory 3418----------------------------------------- 3419 3420FIXME: describe the build system, including what is built in what 3421stages. Also list the various source files that are used in the build 3422process but aren't source files of GCC itself and so aren't documented 3423below (*note Passes::). 3424 3425 3426File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3427 34286.3.4 Makefile Targets 3429---------------------- 3430 3431These targets are available from the `gcc' directory: 3432 3433`all' 3434 This is the default target. Depending on what your 3435 build/host/target configuration is, it coordinates all the things 3436 that need to be built. 3437 3438`doc' 3439 Produce info-formatted documentation and man pages. Essentially it 3440 calls `make man' and `make info'. 3441 3442`dvi' 3443 Produce DVI-formatted documentation. 3444 3445`pdf' 3446 Produce PDF-formatted documentation. 3447 3448`html' 3449 Produce HTML-formatted documentation. 3450 3451`man' 3452 Generate man pages. 3453 3454`info' 3455 Generate info-formatted pages. 3456 3457`mostlyclean' 3458 Delete the files made while building the compiler. 3459 3460`clean' 3461 That, and all the other files built by `make all'. 3462 3463`distclean' 3464 That, and all the files created by `configure'. 3465 3466`maintainer-clean' 3467 Distclean plus any file that can be generated from other files. 3468 Note that additional tools may be required beyond what is normally 3469 needed to build GCC. 3470 3471`srcextra' 3472 Generates files in the source directory that are not 3473 version-controlled but should go into a release tarball. 3474 3475`srcinfo' 3476`srcman' 3477 Copies the info-formatted and manpage documentation into the source 3478 directory usually for the purpose of generating a release tarball. 3479 3480`install' 3481 Installs GCC. 3482 3483`uninstall' 3484 Deletes installed files, though this is not supported. 3485 3486`check' 3487 Run the testsuite. This creates a `testsuite' subdirectory that 3488 has various `.sum' and `.log' files containing the results of the 3489 testing. You can run subsets with, for example, `make check-gcc'. 3490 You can specify specific tests by setting `RUNTESTFLAGS' to be the 3491 name of the `.exp' file, optionally followed by (for some tests) 3492 an equals and a file wildcard, like: 3493 3494 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3495 3496 Note that running the testsuite may require additional tools be 3497 installed, such as Tcl or DejaGnu. 3498 3499 The toplevel tree from which you start GCC compilation is not the GCC 3500directory, but rather a complex Makefile that coordinates the various 3501steps of the build, including bootstrapping the compiler and using the 3502new compiler to build target libraries. 3503 3504 When GCC is configured for a native configuration, the default action 3505for `make' is to do a full three-stage bootstrap. This means that GCC 3506is built three times--once with the native compiler, once with the 3507native-built compiler it just built, and once with the compiler it 3508built the second time. In theory, the last two should produce the same 3509results, which `make compare' can check. Each stage is configured 3510separately and compiled into a separate directory, to minimize problems 3511due to ABI incompatibilities between the native compiler and GCC. 3512 3513 If you do a change, rebuilding will also start from the first stage 3514and "bubble" up the change through the three stages. Each stage is 3515taken from its build directory (if it had been built previously), 3516rebuilt, and copied to its subdirectory. This will allow you to, for 3517example, continue a bootstrap after fixing a bug which causes the 3518stage2 build to crash. It does not provide as good coverage of the 3519compiler as bootstrapping from scratch, but it ensures that the new 3520code is syntactically correct (e.g., that you did not use GCC extensions 3521by mistake), and avoids spurious bootstrap comparison failures(1). 3522 3523 Other targets available from the top level include: 3524 3525`bootstrap-lean' 3526 Like `bootstrap', except that the various stages are removed once 3527 they're no longer needed. This saves disk space. 3528 3529`bootstrap2' 3530`bootstrap2-lean' 3531 Performs only the first two stages of bootstrap. Unlike a 3532 three-stage bootstrap, this does not perform a comparison to test 3533 that the compiler is running properly. Note that the disk space 3534 required by a "lean" bootstrap is approximately independent of the 3535 number of stages. 3536 3537`stageN-bubble (N = 1...4, profile, feedback)' 3538 Rebuild all the stages up to N, with the appropriate flags, 3539 "bubbling" the changes as described above. 3540 3541`all-stageN (N = 1...4, profile, feedback)' 3542 Assuming that stage N has already been built, rebuild it with the 3543 appropriate flags. This is rarely needed. 3544 3545`cleanstrap' 3546 Remove everything (`make clean') and rebuilds (`make bootstrap'). 3547 3548`compare' 3549 Compares the results of stages 2 and 3. This ensures that the 3550 compiler is running properly, since it should produce the same 3551 object files regardless of how it itself was compiled. 3552 3553`profiledbootstrap' 3554 Builds a compiler with profiling feedback information. In this 3555 case, the second and third stages are named `profile' and 3556 `feedback', respectively. For more information, see *note 3557 Building with profile feedback: (gccinstall)Building. 3558 3559`restrap' 3560 Restart a bootstrap, so that everything that was not built with 3561 the system compiler is rebuilt. 3562 3563`stageN-start (N = 1...4, profile, feedback)' 3564 For each package that is bootstrapped, rename directories so that, 3565 for example, `gcc' points to the stageN GCC, compiled with the 3566 stageN-1 GCC(2). 3567 3568 You will invoke this target if you need to test or debug the 3569 stageN GCC. If you only need to execute GCC (but you need not run 3570 `make' either to rebuild it or to run test suites), you should be 3571 able to work directly in the `stageN-gcc' directory. This makes 3572 it easier to debug multiple stages in parallel. 3573 3574`stage' 3575 For each package that is bootstrapped, relocate its build directory 3576 to indicate its stage. For example, if the `gcc' directory points 3577 to the stage2 GCC, after invoking this target it will be renamed 3578 to `stage2-gcc'. 3579 3580 3581 If you wish to use non-default GCC flags when compiling the stage2 and 3582stage3 compilers, set `BOOT_CFLAGS' on the command line when doing 3583`make'. 3584 3585 Usually, the first stage only builds the languages that the compiler 3586is written in: typically, C and maybe Ada. If you are debugging a 3587miscompilation of a different stage2 front-end (for example, of the 3588Fortran front-end), you may want to have front-ends for other languages 3589in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the 3590command line when doing `make'. 3591 3592 For example, in the aforementioned scenario of debugging a Fortran 3593front-end miscompilation caused by the stage1 compiler, you may need a 3594command like 3595 3596 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3597 3598 Alternatively, you can use per-language targets to build and test 3599languages that are not enabled by default in stage1. For example, 3600`make f951' will build a Fortran compiler even in the stage1 build 3601directory. 3602 3603 ---------- Footnotes ---------- 3604 3605 (1) Except if the compiler was buggy and miscompiled some of the files 3606that were not modified. In this case, it's best to use `make restrap'. 3607 3608 (2) Customarily, the system compiler is also termed the `stage0' GCC. 3609 3610 3611File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3612 36136.3.5 Library Source Files and Headers under the `gcc' Directory 3614---------------------------------------------------------------- 3615 3616FIXME: list here, with explanation, all the C source files and headers 3617under the `gcc' directory that aren't built into the GCC executable but 3618rather are part of runtime libraries and object files, such as 3619`crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC: 3620Headers, for more information about the `ginclude' directory. 3621 3622 3623File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3624 36256.3.6 Headers Installed by GCC 3626------------------------------ 3627 3628In general, GCC expects the system C library to provide most of the 3629headers to be used with it. However, GCC will fix those headers if 3630necessary to make them work with GCC, and will install some headers 3631required of freestanding implementations. These headers are installed 3632in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3633installed by GCC; these are not documented here. (FIXME: document them 3634somewhere.) 3635 3636 Several of the headers GCC installs are in the `ginclude' directory. 3637These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are 3638installed in `LIBSUBDIR/include', unless the target Makefile fragment 3639(*note Target Fragment::) overrides this by setting `USER_H'. 3640 3641 In addition to these headers and those generated by fixing system 3642headers to work with GCC, some other headers may also be installed in 3643`LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this 3644specifies additional headers under `config' to be installed on some 3645systems. 3646 3647 GCC installs its own version of `<float.h>', from `ginclude/float.h'. 3648This is done to cope with command-line options that change the 3649representation of floating point numbers. 3650 3651 GCC also installs its own version of `<limits.h>'; this is generated 3652from `glimits.h', together with `limitx.h' and `limity.h' if the system 3653also has its own version of `<limits.h>'. (GCC provides its own header 3654because it is required of ISO C freestanding implementations, but needs 3655to include the system header from its own header as well because other 3656standards such as POSIX specify additional values to be defined in 3657`<limits.h>'.) The system's `<limits.h>' header is used via 3658`LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if 3659it does not need fixing to work with GCC; if it needs fixing, 3660`syslimits.h' is the fixed copy. 3661 3662 GCC can also install `<tgmath.h>'. It will do this when `config.gcc' 3663sets `use_gcc_tgmath' to `yes'. 3664 3665 3666File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3667 36686.3.7 Building Documentation 3669---------------------------- 3670 3671The main GCC documentation is in the form of manuals in Texinfo format. 3672These are installed in Info format; DVI versions may be generated by 3673`make dvi', PDF versions by `make pdf', and HTML versions by `make 3674html'. In addition, some man pages are generated from the Texinfo 3675manuals, there are some other text files with miscellaneous 3676documentation, and runtime libraries have their own documentation 3677outside the `gcc' directory. FIXME: document the documentation for 3678runtime libraries somewhere. 3679 3680* Menu: 3681 3682* Texinfo Manuals:: GCC manuals in Texinfo format. 3683* Man Page Generation:: Generating man pages from Texinfo manuals. 3684* Miscellaneous Docs:: Miscellaneous text files with documentation. 3685 3686 3687File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3688 36896.3.7.1 Texinfo Manuals 3690....................... 3691 3692The manuals for GCC as a whole, and the C and C++ front ends, are in 3693files `doc/*.texi'. Other front ends have their own manuals in files 3694`LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided 3695which may be included in multiple manuals; the following files are in 3696`doc/include': 3697 3698`fdl.texi' 3699 The GNU Free Documentation License. 3700 3701`funding.texi' 3702 The section "Funding Free Software". 3703 3704`gcc-common.texi' 3705 Common definitions for manuals. 3706 3707`gpl_v3.texi' 3708 The GNU General Public License. 3709 3710`texinfo.tex' 3711 A copy of `texinfo.tex' known to work with the GCC manuals. 3712 3713 DVI-formatted manuals are generated by `make dvi', which uses 3714`texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted 3715manuals are generated by `make pdf', which uses `texi2pdf' (via the 3716Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by 3717`make html'. Info manuals are generated by `make info' (which is run 3718as part of a bootstrap); this generates the manuals in the source 3719directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and 3720they are included in release distributions. 3721 3722 Manuals are also provided on the GCC web site, in both HTML and 3723PostScript forms. This is done via the script 3724`maintainer-scripts/update_web_docs_svn'. Each manual to be provided 3725online must be listed in the definition of `MANUALS' in that file; a 3726file `NAME.texi' must only appear once in the source tree, and the 3727output manual must have the same name as the source file. (However, 3728other Texinfo files, included in manuals but not themselves the root 3729files of manuals, may have names that appear more than once in the 3730source tree.) The manual file `NAME.texi' should only include other 3731files in its own directory or in `doc/include'. HTML manuals will be 3732generated by `makeinfo --html', PostScript manuals by `texi2dvi' and 3733`dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are 3734parts of manuals must be version-controlled, even if they are generated 3735files, for the generation of online manuals to work. 3736 3737 The installation manual, `doc/install.texi', is also provided on the 3738GCC web site. The HTML version is generated by the script 3739`doc/install.texi2html'. 3740 3741 3742File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3743 37446.3.7.2 Man Page Generation 3745........................... 3746 3747Because of user demand, in addition to full Texinfo manuals, man pages 3748are provided which contain extracts from those manuals. These man 3749pages are generated from the Texinfo manuals using 3750`contrib/texi2pod.pl' and `pod2man'. (The man page for `g++', 3751`cp/g++.1', just contains a `.so' reference to `gcc.1', but all the 3752other man pages are generated from Texinfo manuals.) 3753 3754 Because many systems may not have the necessary tools installed to 3755generate the man pages, they are only generated if the `configure' 3756script detects that recent enough tools are installed, and the 3757Makefiles allow generating man pages to fail without aborting the 3758build. Man pages are also included in release distributions. They are 3759generated in the source directory. 3760 3761 Magic comments in Texinfo files starting `@c man' control what parts 3762of a Texinfo file go into a man page. Only a subset of Texinfo is 3763supported by `texi2pod.pl', and it may be necessary to add support for 3764more Texinfo features to this script when generating new man pages. To 3765improve the man page output, some special Texinfo macros are provided 3766in `doc/include/gcc-common.texi' which `texi2pod.pl' understands: 3767 3768`@gcctabopt' 3769 Use in the form `@table @gcctabopt' for tables of options, where 3770 for printed output the effect of `@code' is better than that of 3771 `@option' but for man page output a different effect is wanted. 3772 3773`@gccoptlist' 3774 Use for summary lists of options in manuals. 3775 3776`@gol' 3777 Use at the end of each line inside `@gccoptlist'. This is 3778 necessary to avoid problems with differences in how the 3779 `@gccoptlist' macro is handled by different Texinfo formatters. 3780 3781 FIXME: describe the `texi2pod.pl' input language and magic comments in 3782more detail. 3783 3784 3785File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3786 37876.3.7.3 Miscellaneous Documentation 3788................................... 3789 3790In addition to the formal documentation that is installed by GCC, there 3791are several other text files in the `gcc' subdirectory with 3792miscellaneous documentation: 3793 3794`ABOUT-GCC-NLS' 3795 Notes on GCC's Native Language Support. FIXME: this should be 3796 part of this manual rather than a separate file. 3797 3798`ABOUT-NLS' 3799 Notes on the Free Translation Project. 3800 3801`COPYING' 3802`COPYING3' 3803 The GNU General Public License, Versions 2 and 3. 3804 3805`COPYING.LIB' 3806`COPYING3.LIB' 3807 The GNU Lesser General Public License, Versions 2.1 and 3. 3808 3809`*ChangeLog*' 3810`*/ChangeLog*' 3811 Change log files for various parts of GCC. 3812 3813`LANGUAGES' 3814 Details of a few changes to the GCC front-end interface. FIXME: 3815 the information in this file should be part of general 3816 documentation of the front-end interface in this manual. 3817 3818`ONEWS' 3819 Information about new features in old versions of GCC. (For recent 3820 versions, the information is on the GCC web site.) 3821 3822`README.Portability' 3823 Information about portability issues when writing code in GCC. 3824 FIXME: why isn't this part of this manual or of the GCC Coding 3825 Conventions? 3826 3827 FIXME: document such files in subdirectories, at least `config', `c', 3828`cp', `objc', `testsuite'. 3829 3830 3831File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3832 38336.3.8 Anatomy of a Language Front End 3834------------------------------------- 3835 3836A front end for a language in GCC has the following parts: 3837 3838 * A directory `LANGUAGE' under `gcc' containing source files for 3839 that front end. *Note The Front End `LANGUAGE' Directory: Front 3840 End Directory, for details. 3841 3842 * A mention of the language in the list of supported languages in 3843 `gcc/doc/install.texi'. 3844 3845 * A mention of the name under which the language's runtime library is 3846 recognized by `--enable-shared=PACKAGE' in the documentation of 3847 that option in `gcc/doc/install.texi'. 3848 3849 * A mention of any special prerequisites for building the front end 3850 in the documentation of prerequisites in `gcc/doc/install.texi'. 3851 3852 * Details of contributors to that front end in 3853 `gcc/doc/contrib.texi'. If the details are in that front end's 3854 own manual then there should be a link to that manual's list in 3855 `contrib.texi'. 3856 3857 * Information about support for that language in 3858 `gcc/doc/frontends.texi'. 3859 3860 * Information about standards for that language, and the front end's 3861 support for them, in `gcc/doc/standards.texi'. This may be a link 3862 to such information in the front end's own manual. 3863 3864 * Details of source file suffixes for that language and `-x LANG' 3865 options supported, in `gcc/doc/invoke.texi'. 3866 3867 * Entries in `default_compilers' in `gcc.c' for source file suffixes 3868 for that language. 3869 3870 * Preferably testsuites, which may be under `gcc/testsuite' or 3871 runtime library directories. FIXME: document somewhere how to 3872 write testsuite harnesses. 3873 3874 * Probably a runtime library for the language, outside the `gcc' 3875 directory. FIXME: document this further. 3876 3877 * Details of the directories of any runtime libraries in 3878 `gcc/doc/sourcebuild.texi'. 3879 3880 * Check targets in `Makefile.def' for the top-level `Makefile' to 3881 check just the compiler or the compiler and runtime library for the 3882 language. 3883 3884 If the front end is added to the official GCC source repository, the 3885following are also necessary: 3886 3887 * At least one Bugzilla component for bugs in that front end and 3888 runtime libraries. This category needs to be added to the 3889 Bugzilla database. 3890 3891 * Normally, one or more maintainers of that front end listed in 3892 `MAINTAINERS'. 3893 3894 * Mentions on the GCC web site in `index.html' and `frontends.html', 3895 with any relevant links on `readings.html'. (Front ends that are 3896 not an official part of GCC may also be listed on 3897 `frontends.html', with relevant links.) 3898 3899 * A news item on `index.html', and possibly an announcement on the 3900 <gcc-announce@gcc.gnu.org> mailing list. 3901 3902 * The front end's manuals should be mentioned in 3903 `maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::) 3904 and the online manuals should be linked to from 3905 `onlinedocs/index.html'. 3906 3907 * Any old releases or CVS repositories of the front end, before its 3908 inclusion in GCC, should be made available on the GCC FTP site 3909 `ftp://gcc.gnu.org/pub/gcc/old-releases/'. 3910 3911 * The release and snapshot script `maintainer-scripts/gcc_release' 3912 should be updated to generate appropriate tarballs for this front 3913 end. 3914 3915 * If this front end includes its own version files that include the 3916 current date, `maintainer-scripts/update_version' should be 3917 updated accordingly. 3918 3919* Menu: 3920 3921* Front End Directory:: The front end `LANGUAGE' directory. 3922* Front End Config:: The front end `config-lang.in' file. 3923* Front End Makefile:: The front end `Make-lang.in' file. 3924 3925 3926File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3927 39286.3.8.1 The Front End `LANGUAGE' Directory 3929.......................................... 3930 3931A front end `LANGUAGE' directory contains the source files of that 3932front end (but not of any runtime libraries, which should be outside 3933the `gcc' directory). This includes documentation, and possibly some 3934subsidiary programs built alongside the front end. Certain files are 3935special and other parts of the compiler depend on their names: 3936 3937`config-lang.in' 3938 This file is required in all language subdirectories. *Note The 3939 Front End `config-lang.in' File: Front End Config, for details of 3940 its contents 3941 3942`Make-lang.in' 3943 This file is required in all language subdirectories. *Note The 3944 Front End `Make-lang.in' File: Front End Makefile, for details of 3945 its contents. 3946 3947`lang.opt' 3948 This file registers the set of switches that the front end accepts 3949 on the command line, and their `--help' text. *Note Options::. 3950 3951`lang-specs.h' 3952 This file provides entries for `default_compilers' in `gcc.c' 3953 which override the default of giving an error that a compiler for 3954 that language is not installed. 3955 3956`LANGUAGE-tree.def' 3957 This file, which need not exist, defines any language-specific tree 3958 codes. 3959 3960 3961File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3962 39636.3.8.2 The Front End `config-lang.in' File 3964........................................... 3965 3966Each language subdirectory contains a `config-lang.in' file. This file 3967is a shell script that may define some variables describing the 3968language: 3969 3970`language' 3971 This definition must be present, and gives the name of the language 3972 for some purposes such as arguments to `--enable-languages'. 3973 3974`lang_requires' 3975 If defined, this variable lists (space-separated) language front 3976 ends other than C that this front end requires to be enabled (with 3977 the names given being their `language' settings). For example, the 3978 Java front end depends on the C++ front end, so sets 3979 `lang_requires=c++'. 3980 3981`subdir_requires' 3982 If defined, this variable lists (space-separated) front end 3983 directories other than C that this front end requires to be 3984 present. For example, the Objective-C++ front end uses source 3985 files from the C++ and Objective-C front ends, so sets 3986 `subdir_requires="cp objc"'. 3987 3988`target_libs' 3989 If defined, this variable lists (space-separated) targets in the 3990 top level `Makefile' to build the runtime libraries for this 3991 language, such as `target-libobjc'. 3992 3993`lang_dirs' 3994 If defined, this variable lists (space-separated) top level 3995 directories (parallel to `gcc'), apart from the runtime libraries, 3996 that should not be configured if this front end is not built. 3997 3998`build_by_default' 3999 If defined to `no', this language front end is not built unless 4000 enabled in a `--enable-languages' argument. Otherwise, front ends 4001 are built by default, subject to any special logic in 4002 `configure.ac' (as is present to disable the Ada front end if the 4003 Ada compiler is not already installed). 4004 4005`boot_language' 4006 If defined to `yes', this front end is built in stage1 of the 4007 bootstrap. This is only relevant to front ends written in their 4008 own languages. 4009 4010`compilers' 4011 If defined, a space-separated list of compiler executables that 4012 will be run by the driver. The names here will each end with 4013 `\$(exeext)'. 4014 4015`outputs' 4016 If defined, a space-separated list of files that should be 4017 generated by `configure' substituting values in them. This 4018 mechanism can be used to create a file `LANGUAGE/Makefile' from 4019 `LANGUAGE/Makefile.in', but this is deprecated, building 4020 everything from the single `gcc/Makefile' is preferred. 4021 4022`gtfiles' 4023 If defined, a space-separated list of files that should be scanned 4024 by `gengtype.c' to generate the garbage collection tables and 4025 routines for this language. This excludes the files that are 4026 common to all front ends. *Note Type Information::. 4027 4028 4029 4030File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 4031 40326.3.8.3 The Front End `Make-lang.in' File 4033......................................... 4034 4035Each language subdirectory contains a `Make-lang.in' file. It contains 4036targets `LANG.HOOK' (where `LANG' is the setting of `language' in 4037`config-lang.in') for the following values of `HOOK', and any other 4038Makefile rules required to build those targets (which may if necessary 4039use other Makefiles specified in `outputs' in `config-lang.in', 4040although this is deprecated). It also adds any testsuite targets that 4041can use the standard rule in `gcc/Makefile.in' to the variable 4042`lang_checks'. 4043 4044`all.cross' 4045`start.encap' 4046`rest.encap' 4047 FIXME: exactly what goes in each of these targets? 4048 4049`tags' 4050 Build an `etags' `TAGS' file in the language subdirectory in the 4051 source tree. 4052 4053`info' 4054 Build info documentation for the front end, in the build directory. 4055 This target is only called by `make bootstrap' if a suitable 4056 version of `makeinfo' is available, so does not need to check for 4057 this, and should fail if an error occurs. 4058 4059`dvi' 4060 Build DVI documentation for the front end, in the build directory. 4061 This should be done using `$(TEXI2DVI)', with appropriate `-I' 4062 arguments pointing to directories of included files. 4063 4064`pdf' 4065 Build PDF documentation for the front end, in the build directory. 4066 This should be done using `$(TEXI2PDF)', with appropriate `-I' 4067 arguments pointing to directories of included files. 4068 4069`html' 4070 Build HTML documentation for the front end, in the build directory. 4071 4072`man' 4073 Build generated man pages for the front end from Texinfo manuals 4074 (*note Man Page Generation::), in the build directory. This target 4075 is only called if the necessary tools are available, but should 4076 ignore errors so as not to stop the build if errors occur; man 4077 pages are optional and the tools involved may be installed in a 4078 broken way. 4079 4080`install-common' 4081 Install everything that is part of the front end, apart from the 4082 compiler executables listed in `compilers' in `config-lang.in'. 4083 4084`install-info' 4085 Install info documentation for the front end, if it is present in 4086 the source directory. This target should have dependencies on 4087 info files that should be installed. 4088 4089`install-man' 4090 Install man pages for the front end. This target should ignore 4091 errors. 4092 4093`install-plugin' 4094 Install headers needed for plugins. 4095 4096`srcextra' 4097 Copies its dependencies into the source directory. This generally 4098 should be used for generated files such as Bison output files 4099 which are not version-controlled, but should be included in any 4100 release tarballs. This target will be executed during a bootstrap 4101 if `--enable-generated-files-in-srcdir' was specified as a 4102 `configure' option. 4103 4104`srcinfo' 4105`srcman' 4106 Copies its dependencies into the source directory. These targets 4107 will be executed during a bootstrap if 4108 `--enable-generated-files-in-srcdir' was specified as a 4109 `configure' option. 4110 4111`uninstall' 4112 Uninstall files installed by installing the compiler. This is 4113 currently documented not to be supported, so the hook need not do 4114 anything. 4115 4116`mostlyclean' 4117`clean' 4118`distclean' 4119`maintainer-clean' 4120 The language parts of the standard GNU `*clean' targets. *Note 4121 Standard Targets for Users: (standards)Standard Targets, for 4122 details of the standard targets. For GCC, `maintainer-clean' 4123 should delete all generated files in the source directory that are 4124 not version-controlled, but should not delete anything that is. 4125 4126 `Make-lang.in' must also define a variable `LANG_OBJS' to a list of 4127host object files that are used by that language. 4128 4129 4130File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4131 41326.3.9 Anatomy of a Target Back End 4133---------------------------------- 4134 4135A back end for a target architecture in GCC has the following parts: 4136 4137 * A directory `MACHINE' under `gcc/config', containing a machine 4138 description `MACHINE.md' file (*note Machine Descriptions: Machine 4139 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a 4140 source file `MACHINE.c' (*note Target Description Macros and 4141 Functions: Target Macros.), possibly a target Makefile fragment 4142 `t-MACHINE' (*note The Target Makefile Fragment: Target 4143 Fragment.), and maybe some other files. The names of these files 4144 may be changed from the defaults given by explicit specifications 4145 in `config.gcc'. 4146 4147 * If necessary, a file `MACHINE-modes.def' in the `MACHINE' 4148 directory, containing additional machine modes to represent 4149 condition codes. *Note Condition Code::, for further details. 4150 4151 * An optional `MACHINE.opt' file in the `MACHINE' directory, 4152 containing a list of target-specific options. You can also add 4153 other option files using the `extra_options' variable in 4154 `config.gcc'. *Note Options::. 4155 4156 * Entries in `config.gcc' (*note The `config.gcc' File: System 4157 Config.) for the systems with this target architecture. 4158 4159 * Documentation in `gcc/doc/invoke.texi' for any command-line 4160 options supported by this target (*note Run-time Target 4161 Specification: Run-time Target.). This means both entries in the 4162 summary table of options and details of the individual options. 4163 4164 * Documentation in `gcc/doc/extend.texi' for any target-specific 4165 attributes supported (*note Defining target-specific uses of 4166 `__attribute__': Target Attributes.), including where the same 4167 attribute is already supported on some targets, which are 4168 enumerated in the manual. 4169 4170 * Documentation in `gcc/doc/extend.texi' for any target-specific 4171 pragmas supported. 4172 4173 * Documentation in `gcc/doc/extend.texi' of any target-specific 4174 built-in functions supported. 4175 4176 * Documentation in `gcc/doc/extend.texi' of any target-specific 4177 format checking styles supported. 4178 4179 * Documentation in `gcc/doc/md.texi' of any target-specific 4180 constraint letters (*note Constraints for Particular Machines: 4181 Machine Constraints.). 4182 4183 * A note in `gcc/doc/contrib.texi' under the person or people who 4184 contributed the target support. 4185 4186 * Entries in `gcc/doc/install.texi' for all target triplets 4187 supported with this target architecture, giving details of any 4188 special notes about installation for this target, or saying that 4189 there are no special notes if there are none. 4190 4191 * Possibly other support outside the `gcc' directory for runtime 4192 libraries. FIXME: reference docs for this. The `libstdc++' 4193 porting manual needs to be installed as info for this to work, or 4194 to be a chapter of this manual. 4195 4196 If the back end is added to the official GCC source repository, the 4197following are also necessary: 4198 4199 * An entry for the target architecture in `readings.html' on the GCC 4200 web site, with any relevant links. 4201 4202 * Details of the properties of the back end and target architecture 4203 in `backends.html' on the GCC web site. 4204 4205 * A news item about the contribution of support for that target 4206 architecture, in `index.html' on the GCC web site. 4207 4208 * Normally, one or more maintainers of that target listed in 4209 `MAINTAINERS'. Some existing architectures may be unmaintained, 4210 but it would be unusual to add support for a target that does not 4211 have a maintainer when support is added. 4212 4213 * Target triplets covering all `config.gcc' stanzas for the target, 4214 in the list in `contrib/config-list.mk'. 4215 4216 4217File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4218 42197 Testsuites 4220************ 4221 4222GCC contains several testsuites to help maintain compiler quality. 4223Most of the runtime libraries and language front ends in GCC have 4224testsuites. Currently only the C language testsuites are documented 4225here; FIXME: document the others. 4226 4227* Menu: 4228 4229* Test Idioms:: Idioms used in testsuite code. 4230* Test Directives:: Directives used within DejaGnu tests. 4231* Ada Tests:: The Ada language testsuites. 4232* C Tests:: The C language testsuites. 4233* libgcj Tests:: The Java library testsuites. 4234* LTO Testing:: Support for testing link-time optimizations. 4235* gcov Testing:: Support for testing gcov. 4236* profopt Testing:: Support for testing profile-directed optimizations. 4237* compat Testing:: Support for testing binary compatibility. 4238* Torture Tests:: Support for torture testing using multiple options. 4239 4240 4241File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4242 42437.1 Idioms Used in Testsuite Code 4244================================= 4245 4246In general, C testcases have a trailing `-N.c', starting with `-1.c', 4247in case other testcases with similar names are added later. If the 4248test is a test of some well-defined feature, it should have a name 4249referring to that feature such as `FEATURE-1.c'. If it does not test a 4250well-defined feature but just happens to exercise a bug somewhere in 4251the compiler, and a bug report has been filed for this bug in the GCC 4252bug database, `prBUG-NUMBER-1.c' is the appropriate form of name. 4253Otherwise (for miscellaneous bugs not filed in the GCC bug database), 4254and previously more generally, test cases are named after the date on 4255which they were added. This allows people to tell at a glance whether 4256a test failure is because of a recently found bug that has not yet been 4257fixed, or whether it may be a regression, but does not give any other 4258information about the bug or where discussion of it may be found. Some 4259other language testsuites follow similar conventions. 4260 4261 In the `gcc.dg' testsuite, it is often necessary to test that an error 4262is indeed a hard error and not just a warning--for example, where it is 4263a constraint violation in the C standard, which must become an error 4264with `-pedantic-errors'. The following idiom, where the first line 4265shown is line LINE of the file and the line that generates the error, 4266is used for this: 4267 4268 /* { dg-bogus "warning" "warning in place of error" } */ 4269 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4270 4271 It may be necessary to check that an expression is an integer constant 4272expression and has a certain value. To check that `E' has value `V', 4273an idiom similar to the following is used: 4274 4275 char x[((E) == (V) ? 1 : -1)]; 4276 4277 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions 4278about the types of expressions. See, for example, 4279`gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4280rules for the types of conditional expressions in the C standard; see, 4281for example, `gcc.dg/c99-intconst-1.c'. 4282 4283 It is useful to be able to test that optimizations are being made 4284properly. This cannot be done in all cases, but it can be done where 4285the optimization will lead to code being optimized away (for example, 4286where flow analysis or alias analysis should show that certain code 4287cannot be called) or to functions not being called because they have 4288been expanded as built-in functions. Such tests go in 4289`gcc.c-torture/execute'. Where code should be optimized away, a call 4290to a nonexistent function such as `link_failure ()' may be inserted; a 4291definition 4292 4293 #ifndef __OPTIMIZE__ 4294 void 4295 link_failure (void) 4296 { 4297 abort (); 4298 } 4299 #endif 4300 4301will also be needed so that linking still succeeds when the test is run 4302without optimization. When all calls to a built-in function should 4303have been optimized and no calls to the non-built-in version of the 4304function should remain, that function may be defined as `static' to 4305call `abort ()' (although redeclaring a function as static may not work 4306on all targets). 4307 4308 All testcases must be portable. Target-specific testcases must have 4309appropriate code to avoid causing failures on unsupported systems; 4310unfortunately, the mechanisms for this differ by directory. 4311 4312 FIXME: discuss non-C testsuites here. 4313 4314 4315File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4316 43177.2 Directives used within DejaGnu tests 4318======================================== 4319 4320* Menu: 4321 4322* Directives:: Syntax and descriptions of test directives. 4323* Selectors:: Selecting targets to which a test applies. 4324* Effective-Target Keywords:: Keywords describing target attributes. 4325* Add Options:: Features for `dg-add-options' 4326* Require Support:: Variants of `dg-require-SUPPORT' 4327* Final Actions:: Commands for use in `dg-final' 4328 4329 4330File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4331 43327.2.1 Syntax and Descriptions of test directives 4333------------------------------------------------ 4334 4335Test directives appear within comments in a test source file and begin 4336with `dg-'. Some of these are defined within DejaGnu and others are 4337local to the GCC testsuite. 4338 4339 The order in which test directives appear in a test can be important: 4340directives local to GCC sometimes override information used by the 4341DejaGnu directives, which know nothing about the GCC directives, so the 4342DejaGnu directives must precede GCC directives. 4343 4344 Several test directives include selectors (*note Selectors::) which 4345are usually preceded by the keyword `target' or `xfail'. 4346 43477.2.1.1 Specify how to build the test 4348..................................... 4349 4350`{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4351 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4352 is executed. It is one of: 4353 4354 `preprocess' 4355 Compile with `-E' to run only the preprocessor. 4356 4357 `compile' 4358 Compile with `-S' to produce an assembly code file. 4359 4360 `assemble' 4361 Compile with `-c' to produce a relocatable object file. 4362 4363 `link' 4364 Compile, assemble, and link to produce an executable file. 4365 4366 `run' 4367 Produce and run an executable file, which is expected to 4368 return an exit code of 0. 4369 4370 The default is `compile'. That can be overridden for a set of 4371 tests by redefining `dg-do-what-default' within the `.exp' file 4372 for those tests. 4373 4374 If the directive includes the optional `{ target SELECTOR }' then 4375 the test is skipped unless the target system matches the SELECTOR. 4376 4377 If DO-WHAT-KEYWORD is `run' and the directive includes the 4378 optional `{ xfail SELECTOR }' and the selector is met then the 4379 test is expected to fail. The `xfail' clause is ignored for other 4380 values of DO-WHAT-KEYWORD; those tests can use directive 4381 `dg-xfail-if'. 4382 43837.2.1.2 Specify additional compiler options 4384........................................... 4385 4386`{ dg-options OPTIONS [{ target SELECTOR }] }' 4387 This DejaGnu directive provides a list of compiler options, to be 4388 used if the target system matches SELECTOR, that replace the 4389 default options used for this set of tests. 4390 4391`{ dg-add-options FEATURE ... }' 4392 Add any compiler options that are needed to access certain 4393 features. This directive does nothing on targets that enable the 4394 features by default, or that don't provide them at all. It must 4395 come after all `dg-options' directives. For supported values of 4396 FEATURE see *note Add Options::. 4397 4398`{ dg-additional-options OPTIONS [{ target SELECTOR }] }' 4399 This directive provides a list of compiler options, to be used if 4400 the target system matches SELECTOR, that are added to the default 4401 options used for this set of tests. 4402 44037.2.1.3 Modify the test timeout value 4404..................................... 4405 4406The normal timeout limit, in seconds, is found by searching the 4407following in order: 4408 4409 * the value defined by an earlier `dg-timeout' directive in the test 4410 4411 * variable TOOL_TIMEOUT defined by the set of tests 4412 4413 * GCC,TIMEOUT set in the target board 4414 4415 * 300 4416 4417`{ dg-timeout N [{target SELECTOR }] }' 4418 Set the time limit for the compilation and for the execution of 4419 the test to the specified number of seconds. 4420 4421`{ dg-timeout-factor X [{ target SELECTOR }] }' 4422 Multiply the normal time limit for compilation and execution of 4423 the test by the specified floating-point factor. 4424 44257.2.1.4 Skip a test for some targets 4426.................................... 4427 4428`{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4429 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4430 element is a string of zero or more GCC options. Skip the test if 4431 all of the following conditions are met: 4432 * the test system is included in SELECTOR 4433 4434 * for at least one of the option strings in INCLUDE-OPTS, every 4435 option from that string is in the set of options with which 4436 the test would be compiled; use `"*"' for an INCLUDE-OPTS list 4437 that matches any options; that is the default if INCLUDE-OPTS 4438 is not specified 4439 4440 * for each of the option strings in EXCLUDE-OPTS, at least one 4441 option from that string is not in the set of options with 4442 which the test would be compiled; use `""' for an empty 4443 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4444 specified 4445 4446 For example, to skip a test if option `-Os' is present: 4447 4448 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4449 4450 To skip a test if both options `-O2' and `-g' are present: 4451 4452 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4453 4454 To skip a test if either `-O2' or `-O3' is present: 4455 4456 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4457 4458 To skip a test unless option `-Os' is present: 4459 4460 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4461 4462 To skip a test if either `-O2' or `-O3' is used with `-g' but not 4463 if `-fpic' is also present: 4464 4465 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4466 4467`{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4468 Skip the test if the test target, including current multilib flags, 4469 is not covered by the effective-target keyword. If the directive 4470 includes the optional `{ SELECTOR }' then the effective-target 4471 test is only performed if the target system matches the SELECTOR. 4472 This directive must appear after any `dg-do' directive in the test 4473 and before any `dg-additional-sources' directive. *Note 4474 Effective-Target Keywords::. 4475 4476`{ dg-require-SUPPORT args }' 4477 Skip the test if the target does not provide the required support. 4478 These directives must appear after any `dg-do' directive in the 4479 test and before any `dg-additional-sources' directive. They 4480 require at least one argument, which can be an empty string if the 4481 specific procedure does not examine the argument. *Note Require 4482 Support::, for a complete list of these directives. 4483 44847.2.1.5 Expect a test to fail for some targets 4485.............................................. 4486 4487`{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4488 Expect the test to fail if the conditions (which are the same as 4489 for `dg-skip-if') are met. This does not affect the execute step. 4490 4491`{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4492 Expect the execute step of a test to fail if the conditions (which 4493 are the same as for `dg-skip-if') are met. 4494 44957.2.1.6 Expect the test executable to fail 4496.......................................... 4497 4498`{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4499 Expect the test executable to return a nonzero exit status if the 4500 conditions (which are the same as for `dg-skip-if') are met. 4501 45027.2.1.7 Verify compiler messages 4503................................ 4504 4505`{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4506 This DejaGnu directive appears on a source line that is expected 4507 to get an error message, or else specifies the source line 4508 associated with the message. If there is no message for that line 4509 or if the text of that message is not matched by REGEXP then the 4510 check fails and COMMENT is included in the `FAIL' message. The 4511 check does not look for the string `error' unless it is part of 4512 REGEXP. 4513 4514`{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4515 This DejaGnu directive appears on a source line that is expected 4516 to get a warning message, or else specifies the source line 4517 associated with the message. If there is no message for that line 4518 or if the text of that message is not matched by REGEXP then the 4519 check fails and COMMENT is included in the `FAIL' message. The 4520 check does not look for the string `warning' unless it is part of 4521 REGEXP. 4522 4523`{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4524 The line is expected to get a message other than an error or 4525 warning. If there is no message for that line or if the text of 4526 that message is not matched by REGEXP then the check fails and 4527 COMMENT is included in the `FAIL' message. 4528 4529`{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4530 This DejaGnu directive appears on a source line that should not 4531 get a message matching REGEXP, or else specifies the source line 4532 associated with the bogus message. It is usually used with `xfail' 4533 to indicate that the message is a known problem for a particular 4534 set of targets. 4535 4536`{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4537 This DejaGnu directive indicates that the test is expected to fail 4538 due to compiler messages that are not handled by `dg-error', 4539 `dg-warning' or `dg-bogus'. For this directive `xfail' has the 4540 same effect as `target'. 4541 4542`{ dg-prune-output REGEXP }' 4543 Prune messages matching REGEXP from the test output. 4544 45457.2.1.8 Verify output of the test executable 4546............................................ 4547 4548`{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4549 This DejaGnu directive compares REGEXP to the combined output that 4550 the test executable writes to `stdout' and `stderr'. 4551 45527.2.1.9 Specify additional files for a test 4553........................................... 4554 4555`{ dg-additional-files "FILELIST" }' 4556 Specify additional files, other than source files, that must be 4557 copied to the system where the compiler runs. 4558 4559`{ dg-additional-sources "FILELIST" }' 4560 Specify additional source files to appear in the compile line 4561 following the main test file. 4562 45637.2.1.10 Add checks at the end of a test 4564........................................ 4565 4566`{ dg-final { LOCAL-DIRECTIVE } }' 4567 This DejaGnu directive is placed within a comment anywhere in the 4568 source file and is processed after the test has been compiled and 4569 run. Multiple `dg-final' commands are processed in the order in 4570 which they appear in the source file. *Note Final Actions::, for 4571 a list of directives that can be used within `dg-final'. 4572 4573 4574File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4575 45767.2.2 Selecting targets to which a test applies 4577----------------------------------------------- 4578 4579Several test directives include SELECTORs to limit the targets for 4580which a test is run or to declare that a test is expected to fail on 4581particular targets. 4582 4583 A selector is: 4584 * one or more target triplets, possibly including wildcard 4585 characters; use `*-*-*' to match any target 4586 4587 * a single effective-target keyword (*note Effective-Target 4588 Keywords::) 4589 4590 * a logical expression 4591 4592 Depending on the context, the selector specifies whether a test is 4593skipped and reported as unsupported or is expected to fail. A context 4594that allows either `target' or `xfail' also allows `{ target SELECTOR1 4595xfail SELECTOR2 }' to skip the test for targets that don't match 4596SELECTOR1 and the test to fail for targets that match SELECTOR2. 4597 4598 A selector expression appears within curly braces and uses a single 4599logical operator: one of `!', `&&', or `||'. An operand is another 4600selector expression, an effective-target keyword, a single target 4601triplet, or a list of target triplets within quotes or curly braces. 4602For example: 4603 4604 { target { ! "hppa*-*-* ia64*-*-*" } } 4605 { target { powerpc*-*-* && lp64 } } 4606 { xfail { lp64 || vect_no_align } } 4607 4608 4609File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4610 46117.2.3 Keywords describing target attributes 4612------------------------------------------- 4613 4614Effective-target keywords identify sets of targets that support 4615particular functionality. They are used to limit tests to be run only 4616for particular targets, or to specify that particular sets of targets 4617are expected to fail some tests. 4618 4619 Effective-target keywords are defined in `lib/target-supports.exp' in 4620the GCC testsuite, with the exception of those that are documented as 4621being local to a particular test directory. 4622 4623 The `effective target' takes into account all of the compiler options 4624with which the test will be compiled, including the multilib options. 4625By convention, keywords ending in `_nocache' can also include options 4626specified for the particular test in an earlier `dg-options' or 4627`dg-add-options' directive. 4628 46297.2.3.1 Data type sizes 4630....................... 4631 4632`ilp32' 4633 Target has 32-bit `int', `long', and pointers. 4634 4635`lp64' 4636 Target has 32-bit `int', 64-bit `long' and pointers. 4637 4638`llp64' 4639 Target has 32-bit `int' and `long', 64-bit `long long' and 4640 pointers. 4641 4642`double64' 4643 Target has 64-bit `double'. 4644 4645`double64plus' 4646 Target has `double' that is 64 bits or longer. 4647 4648`longdouble128' 4649 Target has 128-bit `long double'. 4650 4651`int32plus' 4652 Target has `int' that is at 32 bits or longer. 4653 4654`int16' 4655 Target has `int' that is 16 bits or shorter. 4656 4657`long_neq_int' 4658 Target has `int' and `long' with different sizes. 4659 4660`large_double' 4661 Target supports `double' that is longer than `float'. 4662 4663`large_long_double' 4664 Target supports `long double' that is longer than `double'. 4665 4666`ptr32plus' 4667 Target has pointers that are 32 bits or longer. 4668 4669`size32plus' 4670 Target supports array and structure sizes that are 32 bits or 4671 longer. 4672 4673`4byte_wchar_t' 4674 Target has `wchar_t' that is at least 4 bytes. 4675 46767.2.3.2 Fortran-specific attributes 4677................................... 4678 4679`fortran_integer_16' 4680 Target supports Fortran `integer' that is 16 bytes or longer. 4681 4682`fortran_large_int' 4683 Target supports Fortran `integer' kinds larger than `integer(8)'. 4684 4685`fortran_large_real' 4686 Target supports Fortran `real' kinds larger than `real(8)'. 4687 46887.2.3.3 Vector-specific attributes 4689.................................. 4690 4691`vect_condition' 4692 Target supports vector conditional operations. 4693 4694`vect_double' 4695 Target supports hardware vectors of `double'. 4696 4697`vect_float' 4698 Target supports hardware vectors of `float'. 4699 4700`vect_int' 4701 Target supports hardware vectors of `int'. 4702 4703`vect_long' 4704 Target supports hardware vectors of `long'. 4705 4706`vect_long_long' 4707 Target supports hardware vectors of `long long'. 4708 4709`vect_aligned_arrays' 4710 Target aligns arrays to vector alignment boundary. 4711 4712`vect_hw_misalign' 4713 Target supports a vector misalign access. 4714 4715`vect_no_align' 4716 Target does not support a vector alignment mechanism. 4717 4718`vect_no_int_max' 4719 Target does not support a vector max instruction on `int'. 4720 4721`vect_no_int_add' 4722 Target does not support a vector add instruction on `int'. 4723 4724`vect_no_bitwise' 4725 Target does not support vector bitwise instructions. 4726 4727`vect_char_mult' 4728 Target supports `vector char' multiplication. 4729 4730`vect_short_mult' 4731 Target supports `vector short' multiplication. 4732 4733`vect_int_mult' 4734 Target supports `vector int' multiplication. 4735 4736`vect_extract_even_odd' 4737 Target supports vector even/odd element extraction. 4738 4739`vect_extract_even_odd_wide' 4740 Target supports vector even/odd element extraction of vectors with 4741 elements `SImode' or larger. 4742 4743`vect_interleave' 4744 Target supports vector interleaving. 4745 4746`vect_strided' 4747 Target supports vector interleaving and extract even/odd. 4748 4749`vect_strided_wide' 4750 Target supports vector interleaving and extract even/odd for wide 4751 element types. 4752 4753`vect_perm' 4754 Target supports vector permutation. 4755 4756`vect_shift' 4757 Target supports a hardware vector shift operation. 4758 4759`vect_widen_sum_hi_to_si' 4760 Target supports a vector widening summation of `short' operands 4761 into `int' results, or can promote (unpack) from `short' to `int'. 4762 4763`vect_widen_sum_qi_to_hi' 4764 Target supports a vector widening summation of `char' operands 4765 into `short' results, or can promote (unpack) from `char' to 4766 `short'. 4767 4768`vect_widen_sum_qi_to_si' 4769 Target supports a vector widening summation of `char' operands 4770 into `int' results. 4771 4772`vect_widen_mult_qi_to_hi' 4773 Target supports a vector widening multiplication of `char' operands 4774 into `short' results, or can promote (unpack) from `char' to 4775 `short' and perform non-widening multiplication of `short'. 4776 4777`vect_widen_mult_hi_to_si' 4778 Target supports a vector widening multiplication of `short' 4779 operands into `int' results, or can promote (unpack) from `short' 4780 to `int' and perform non-widening multiplication of `int'. 4781 4782`vect_sdot_qi' 4783 Target supports a vector dot-product of `signed char'. 4784 4785`vect_udot_qi' 4786 Target supports a vector dot-product of `unsigned char'. 4787 4788`vect_sdot_hi' 4789 Target supports a vector dot-product of `signed short'. 4790 4791`vect_udot_hi' 4792 Target supports a vector dot-product of `unsigned short'. 4793 4794`vect_pack_trunc' 4795 Target supports a vector demotion (packing) of `short' to `char' 4796 and from `int' to `short' using modulo arithmetic. 4797 4798`vect_unpack' 4799 Target supports a vector promotion (unpacking) of `char' to `short' 4800 and from `char' to `int'. 4801 4802`vect_intfloat_cvt' 4803 Target supports conversion from `signed int' to `float'. 4804 4805`vect_uintfloat_cvt' 4806 Target supports conversion from `unsigned int' to `float'. 4807 4808`vect_floatint_cvt' 4809 Target supports conversion from `float' to `signed int'. 4810 4811`vect_floatuint_cvt' 4812 Target supports conversion from `float' to `unsigned int'. 4813 48147.2.3.4 Thread Local Storage attributes 4815....................................... 4816 4817`tls' 4818 Target supports thread-local storage. 4819 4820`tls_native' 4821 Target supports native (rather than emulated) thread-local storage. 4822 4823`tls_runtime' 4824 Test system supports executing TLS executables. 4825 48267.2.3.5 Decimal floating point attributes 4827......................................... 4828 4829`dfp' 4830 Targets supports compiling decimal floating point extension to C. 4831 4832`dfp_nocache' 4833 Including the options used to compile this particular test, the 4834 target supports compiling decimal floating point extension to C. 4835 4836`dfprt' 4837 Test system can execute decimal floating point tests. 4838 4839`dfprt_nocache' 4840 Including the options used to compile this particular test, the 4841 test system can execute decimal floating point tests. 4842 4843`hard_dfp' 4844 Target generates decimal floating point instructions with current 4845 options. 4846 48477.2.3.6 ARM-specific attributes 4848............................... 4849 4850`arm32' 4851 ARM target generates 32-bit code. 4852 4853`arm_eabi' 4854 ARM target adheres to the ABI for the ARM Architecture. 4855 4856`arm_hf_eabi' 4857 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4858 variant of the ABI for the ARM Architecture (as selected with 4859 `-mfloat-abi=hard'). 4860 4861`arm_hard_vfp_ok' 4862 ARM target supports `-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4863 may be incompatible with these options. 4864 4865`arm_iwmmxt_ok' 4866 ARM target supports `-mcpu=iwmmxt'. Some multilibs may be 4867 incompatible with this option. 4868 4869`arm_neon' 4870 ARM target supports generating NEON instructions. 4871 4872`arm_neon_hw' 4873 Test system supports executing NEON instructions. 4874 4875`arm_neonv2_hw' 4876 Test system supports executing NEON v2 instructions. 4877 4878`arm_neon_ok' 4879 ARM Target supports `-mfpu=neon -mfloat-abi=softfp' or compatible 4880 options. Some multilibs may be incompatible with these options. 4881 4882`arm_neonv2_ok' 4883 ARM Target supports `-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4884 compatible options. Some multilibs may be incompatible with these 4885 options. 4886 4887`arm_neon_fp16_ok' 4888 ARM Target supports `-mfpu=neon-fp16 -mfloat-abi=softfp' or 4889 compatible options. Some multilibs may be incompatible with these 4890 options. 4891 4892`arm_thumb1_ok' 4893 ARM target generates Thumb-1 code for `-mthumb'. 4894 4895`arm_thumb2_ok' 4896 ARM target generates Thumb-2 code for `-mthumb'. 4897 4898`arm_vfp_ok' 4899 ARM target supports `-mfpu=vfp -mfloat-abi=softfp'. Some 4900 multilibs may be incompatible with these options. 4901 4902`arm_v8_vfp_ok' 4903 ARM target supports `-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 4904 multilibs may be incompatible with these options. 4905 4906`arm_v8_neon_ok' 4907 ARM target supports `-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. 4908 Some multilibs may be incompatible with these options. 4909 4910`arm_prefer_ldrd_strd' 4911 ARM target prefers `LDRD' and `STRD' instructions over `LDM' and 4912 `STM' instructions. 4913 4914 49157.2.3.7 MIPS-specific attributes 4916................................ 4917 4918`mips64' 4919 MIPS target supports 64-bit instructions. 4920 4921`nomips16' 4922 MIPS target does not produce MIPS16 code. 4923 4924`mips16_attribute' 4925 MIPS target can generate MIPS16 code. 4926 4927`mips_loongson' 4928 MIPS target is a Loongson-2E or -2F target using an ABI that 4929 supports the Loongson vector modes. 4930 4931`mips_newabi_large_long_double' 4932 MIPS target supports `long double' larger than `double' when using 4933 the new ABI. 4934 4935`mpaired_single' 4936 MIPS target supports `-mpaired-single'. 4937 49387.2.3.8 PowerPC-specific attributes 4939................................... 4940 4941`dfp_hw' 4942 PowerPC target supports executing hardware DFP instructions. 4943 4944`p8vector_hw' 4945 PowerPC target supports executing VSX instructions (ISA 2.07). 4946 4947`powerpc64' 4948 Test system supports executing 64-bit instructions. 4949 4950`powerpc_altivec' 4951 PowerPC target supports AltiVec. 4952 4953`powerpc_altivec_ok' 4954 PowerPC target supports `-maltivec'. 4955 4956`powerpc_eabi_ok' 4957 PowerPC target supports `-meabi'. 4958 4959`powerpc_elfv2' 4960 PowerPC target supports `-mabi=elfv2'. 4961 4962`powerpc_fprs' 4963 PowerPC target supports floating-point registers. 4964 4965`powerpc_hard_double' 4966 PowerPC target supports hardware double-precision floating-point. 4967 4968`powerpc_htm_ok' 4969 PowerPC target supports `-mhtm' 4970 4971`powerpc_p8vector_ok' 4972 PowerPC target supports `-mpower8-vector' 4973 4974`powerpc_ppu_ok' 4975 PowerPC target supports `-mcpu=cell'. 4976 4977`powerpc_spe' 4978 PowerPC target supports PowerPC SPE. 4979 4980`powerpc_spe_nocache' 4981 Including the options used to compile this particular test, the 4982 PowerPC target supports PowerPC SPE. 4983 4984`powerpc_spu' 4985 PowerPC target supports PowerPC SPU. 4986 4987`powerpc_vsx_ok' 4988 PowerPC target supports `-mvsx'. 4989 4990`powerpc_405_nocache' 4991 Including the options used to compile this particular test, the 4992 PowerPC target supports PowerPC 405. 4993 4994`ppc_recip_hw' 4995 PowerPC target supports executing reciprocal estimate instructions. 4996 4997`spu_auto_overlay' 4998 SPU target has toolchain that supports automatic overlay 4999 generation. 5000 5001`vmx_hw' 5002 PowerPC target supports executing AltiVec instructions. 5003 5004`vsx_hw' 5005 PowerPC target supports executing VSX instructions (ISA 2.06). 5006 50077.2.3.9 Other hardware attributes 5008................................. 5009 5010`avx' 5011 Target supports compiling `avx' instructions. 5012 5013`avx_runtime' 5014 Target supports the execution of `avx' instructions. 5015 5016`cell_hw' 5017 Test system can execute AltiVec and Cell PPU instructions. 5018 5019`coldfire_fpu' 5020 Target uses a ColdFire FPU. 5021 5022`hard_float' 5023 Target supports FPU instructions. 5024 5025`sse' 5026 Target supports compiling `sse' instructions. 5027 5028`sse_runtime' 5029 Target supports the execution of `sse' instructions. 5030 5031`sse2' 5032 Target supports compiling `sse2' instructions. 5033 5034`sse2_runtime' 5035 Target supports the execution of `sse2' instructions. 5036 5037`sync_char_short' 5038 Target supports atomic operations on `char' and `short'. 5039 5040`sync_int_long' 5041 Target supports atomic operations on `int' and `long'. 5042 5043`ultrasparc_hw' 5044 Test environment appears to run executables on a simulator that 5045 accepts only `EM_SPARC' executables and chokes on `EM_SPARC32PLUS' 5046 or `EM_SPARCV9' executables. 5047 5048`vect_cmdline_needed' 5049 Target requires a command line argument to enable a SIMD 5050 instruction set. 5051 50527.2.3.10 Environment attributes 5053............................... 5054 5055`c' 5056 The language for the compiler under test is C. 5057 5058`c++' 5059 The language for the compiler under test is C++. 5060 5061`c99_runtime' 5062 Target provides a full C99 runtime. 5063 5064`correct_iso_cpp_string_wchar_protos' 5065 Target `string.h' and `wchar.h' headers provide C++ required 5066 overloads for `strchr' etc. functions. 5067 5068`dummy_wcsftime' 5069 Target uses a dummy `wcsftime' function that always returns zero. 5070 5071`fd_truncate' 5072 Target can truncate a file from a file descriptor, as used by 5073 `libgfortran/io/unix.c:fd_truncate'; i.e. `ftruncate' or `chsize'. 5074 5075`freestanding' 5076 Target is `freestanding' as defined in section 4 of the C99 5077 standard. Effectively, it is a target which supports no extra 5078 headers or libraries other than what is considered essential. 5079 5080`init_priority' 5081 Target supports constructors with initialization priority 5082 arguments. 5083 5084`inttypes_types' 5085 Target has the basic signed and unsigned types in `inttypes.h'. 5086 This is for tests that GCC's notions of these types agree with 5087 those in the header, as some systems have only `inttypes.h'. 5088 5089`lax_strtofp' 5090 Target might have errors of a few ULP in string to floating-point 5091 conversion functions and overflow is not always detected correctly 5092 by those functions. 5093 5094`mmap' 5095 Target supports `mmap'. 5096 5097`newlib' 5098 Target supports Newlib. 5099 5100`pow10' 5101 Target provides `pow10' function. 5102 5103`pthread' 5104 Target can compile using `pthread.h' with no errors or warnings. 5105 5106`pthread_h' 5107 Target has `pthread.h'. 5108 5109`run_expensive_tests' 5110 Expensive testcases (usually those that consume excessive amounts 5111 of CPU time) should be run on this target. This can be enabled by 5112 setting the `GCC_TEST_RUN_EXPENSIVE' environment variable to a 5113 non-empty string. 5114 5115`simulator' 5116 Test system runs executables on a simulator (i.e. slowly) rather 5117 than hardware (i.e. fast). 5118 5119`stdint_types' 5120 Target has the basic signed and unsigned C types in `stdint.h'. 5121 This will be obsolete when GCC ensures a working `stdint.h' for 5122 all targets. 5123 5124`trampolines' 5125 Target supports trampolines. 5126 5127`uclibc' 5128 Target supports uClibc. 5129 5130`unwrapped' 5131 Target does not use a status wrapper. 5132 5133`vxworks_kernel' 5134 Target is a VxWorks kernel. 5135 5136`vxworks_rtp' 5137 Target is a VxWorks RTP. 5138 5139`wchar' 5140 Target supports wide characters. 5141 51427.2.3.11 Other attributes 5143......................... 5144 5145`automatic_stack_alignment' 5146 Target supports automatic stack alignment. 5147 5148`cxa_atexit' 5149 Target uses `__cxa_atexit'. 5150 5151`default_packed' 5152 Target has packed layout of structure members by default. 5153 5154`fgraphite' 5155 Target supports Graphite optimizations. 5156 5157`fixed_point' 5158 Target supports fixed-point extension to C. 5159 5160`fopenmp' 5161 Target supports OpenMP via `-fopenmp'. 5162 5163`fpic' 5164 Target supports `-fpic' and `-fPIC'. 5165 5166`freorder' 5167 Target supports `-freorder-blocks-and-partition'. 5168 5169`fstack_protector' 5170 Target supports `-fstack-protector'. 5171 5172`gas' 5173 Target uses GNU `as'. 5174 5175`gc_sections' 5176 Target supports `--gc-sections'. 5177 5178`gld' 5179 Target uses GNU `ld'. 5180 5181`keeps_null_pointer_checks' 5182 Target keeps null pointer checks, either due to the use of 5183 `-fno-delete-null-pointer-checks' or hardwired into the target. 5184 5185`lto' 5186 Compiler has been configured to support link-time optimization 5187 (LTO). 5188 5189`naked_functions' 5190 Target supports the `naked' function attribute. 5191 5192`named_sections' 5193 Target supports named sections. 5194 5195`natural_alignment_32' 5196 Target uses natural alignment (aligned to type size) for types of 5197 32 bits or less. 5198 5199`target_natural_alignment_64' 5200 Target uses natural alignment (aligned to type size) for types of 5201 64 bits or less. 5202 5203`nonpic' 5204 Target does not generate PIC by default. 5205 5206`pcc_bitfield_type_matters' 5207 Target defines `PCC_BITFIELD_TYPE_MATTERS'. 5208 5209`pe_aligned_commons' 5210 Target supports `-mpe-aligned-commons'. 5211 5212`pie' 5213 Target supports `-pie', `-fpie' and `-fPIE'. 5214 5215`section_anchors' 5216 Target supports section anchors. 5217 5218`short_enums' 5219 Target defaults to short enums. 5220 5221`static' 5222 Target supports `-static'. 5223 5224`static_libgfortran' 5225 Target supports statically linking `libgfortran'. 5226 5227`string_merging' 5228 Target supports merging string constants at link time. 5229 5230`ucn' 5231 Target supports compiling and assembling UCN. 5232 5233`ucn_nocache' 5234 Including the options used to compile this particular test, the 5235 target supports compiling and assembling UCN. 5236 5237`unaligned_stack' 5238 Target does not guarantee that its `STACK_BOUNDARY' is greater than 5239 or equal to the required vector alignment. 5240 5241`vector_alignment_reachable' 5242 Vector alignment is reachable for types of 32 bits or less. 5243 5244`vector_alignment_reachable_for_64bit' 5245 Vector alignment is reachable for types of 64 bits or less. 5246 5247`wchar_t_char16_t_compatible' 5248 Target supports `wchar_t' that is compatible with `char16_t'. 5249 5250`wchar_t_char32_t_compatible' 5251 Target supports `wchar_t' that is compatible with `char32_t'. 5252 52537.2.3.12 Local to tests in `gcc.target/i386' 5254............................................ 5255 5256`3dnow' 5257 Target supports compiling `3dnow' instructions. 5258 5259`aes' 5260 Target supports compiling `aes' instructions. 5261 5262`fma4' 5263 Target supports compiling `fma4' instructions. 5264 5265`ms_hook_prologue' 5266 Target supports attribute `ms_hook_prologue'. 5267 5268`pclmul' 5269 Target supports compiling `pclmul' instructions. 5270 5271`sse3' 5272 Target supports compiling `sse3' instructions. 5273 5274`sse4' 5275 Target supports compiling `sse4' instructions. 5276 5277`sse4a' 5278 Target supports compiling `sse4a' instructions. 5279 5280`ssse3' 5281 Target supports compiling `ssse3' instructions. 5282 5283`vaes' 5284 Target supports compiling `vaes' instructions. 5285 5286`vpclmul' 5287 Target supports compiling `vpclmul' instructions. 5288 5289`xop' 5290 Target supports compiling `xop' instructions. 5291 52927.2.3.13 Local to tests in `gcc.target/spu/ea' 5293.............................................. 5294 5295`ealib' 5296 Target `__ea' library functions are available. 5297 52987.2.3.14 Local to tests in `gcc.test-framework' 5299............................................... 5300 5301`no' 5302 Always returns 0. 5303 5304`yes' 5305 Always returns 1. 5306 5307 5308File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5309 53107.2.4 Features for `dg-add-options' 5311----------------------------------- 5312 5313The supported values of FEATURE for directive `dg-add-options' are: 5314 5315`arm_neon' 5316 NEON support. Only ARM targets support this feature, and only then 5317 in certain modes; see the *note arm_neon_ok effective target 5318 keyword: arm_neon_ok. 5319 5320`arm_neon_fp16' 5321 NEON and half-precision floating point support. Only ARM targets 5322 support this feature, and only then in certain modes; see the 5323 *note arm_neon_fp16_ok effective target keyword: arm_neon_ok. 5324 5325`bind_pic_locally' 5326 Add the target-specific flags needed to enable functions to bind 5327 locally when using pic/PIC passes in the testsuite. 5328 5329`c99_runtime' 5330 Add the target-specific flags needed to access the C99 runtime. 5331 5332`ieee' 5333 Add the target-specific flags needed to enable full IEEE 5334 compliance mode. 5335 5336`mips16_attribute' 5337 `mips16' function attributes. Only MIPS targets support this 5338 feature, and only then in certain modes. 5339 5340`tls' 5341 Add the target-specific flags needed to use thread-local storage. 5342 5343 5344File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5345 53467.2.5 Variants of `dg-require-SUPPORT' 5347-------------------------------------- 5348 5349A few of the `dg-require' directives take arguments. 5350 5351`dg-require-iconv CODESET' 5352 Skip the test if the target does not support iconv. CODESET is 5353 the codeset to convert to. 5354 5355`dg-require-profiling PROFOPT' 5356 Skip the test if the target does not support profiling with option 5357 PROFOPT. 5358 5359`dg-require-visibility VIS' 5360 Skip the test if the target does not support the `visibility' 5361 attribute. If VIS is `""', support for `visibility("hidden")' is 5362 checked, for `visibility("VIS")' otherwise. 5363 5364 The original `dg-require' directives were defined before there was 5365support for effective-target keywords. The directives that do not take 5366arguments could be replaced with effective-target keywords. 5367 5368`dg-require-alias ""' 5369 Skip the test if the target does not support the `alias' attribute. 5370 5371`dg-require-ascii-locale ""' 5372 Skip the test if the host does not support an ASCII locale. 5373 5374`dg-require-compat-dfp ""' 5375 Skip this test unless both compilers in a `compat' testsuite 5376 support decimal floating point. 5377 5378`dg-require-cxa-atexit ""' 5379 Skip the test if the target does not support `__cxa_atexit'. This 5380 is equivalent to `dg-require-effective-target cxa_atexit'. 5381 5382`dg-require-dll ""' 5383 Skip the test if the target does not support DLL attributes. 5384 5385`dg-require-fork ""' 5386 Skip the test if the target does not support `fork'. 5387 5388`dg-require-gc-sections ""' 5389 Skip the test if the target's linker does not support the 5390 `--gc-sections' flags. This is equivalent to 5391 `dg-require-effective-target gc-sections'. 5392 5393`dg-require-host-local ""' 5394 Skip the test if the host is remote, rather than the same as the 5395 build system. Some tests are incompatible with DejaGnu's handling 5396 of remote hosts, which involves copying the source file to the 5397 host and compiling it with a relative path and "`-o a.out'". 5398 5399`dg-require-mkfifo ""' 5400 Skip the test if the target does not support `mkfifo'. 5401 5402`dg-require-named-sections ""' 5403 Skip the test is the target does not support named sections. This 5404 is equivalent to `dg-require-effective-target named_sections'. 5405 5406`dg-require-weak ""' 5407 Skip the test if the target does not support weak symbols. 5408 5409`dg-require-weak-override ""' 5410 Skip the test if the target does not support overriding weak 5411 symbols. 5412 5413 5414File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5415 54167.2.6 Commands for use in `dg-final' 5417------------------------------------ 5418 5419The GCC testsuite defines the following directives to be used within 5420`dg-final'. 5421 54227.2.6.1 Scan a particular file 5423.............................. 5424 5425`scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5426 Passes if REGEXP matches text in FILENAME. 5427 5428`scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5429 Passes if REGEXP does not match text in FILENAME. 5430 5431`scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5432 Passes if REGEXP matches in Fortran module MODULE. 5433 54347.2.6.2 Scan the assembly output 5435................................ 5436 5437`scan-assembler REGEX [{ target/xfail SELECTOR }]' 5438 Passes if REGEX matches text in the test's assembler output. 5439 5440`scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5441 Passes if REGEX does not match text in the test's assembler output. 5442 5443`scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5444 Passes if REGEX is matched exactly NUM times in the test's 5445 assembler output. 5446 5447`scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5448 Passes if REGEX matches text in the test's demangled assembler 5449 output. 5450 5451`scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5452 Passes if REGEX does not match text in the test's demangled 5453 assembler output. 5454 5455`scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5456 Passes if SYMBOL is defined as a hidden symbol in the test's 5457 assembly output. 5458 5459`scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5460 Passes if SYMBOL is not defined as a hidden symbol in the test's 5461 assembly output. 5462 54637.2.6.3 Scan optimization dump files 5464.................................... 5465 5466These commands are available for KIND of `tree', `rtl', and `ipa'. 5467 5468`scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5469 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5470 5471`scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5472 Passes if REGEX does not match text in the dump file with suffix 5473 SUFFIX. 5474 5475`scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5476 Passes if REGEX is found exactly NUM times in the dump file with 5477 suffix SUFFIX. 5478 5479`scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5480 Passes if REGEX matches demangled text in the dump file with 5481 suffix SUFFIX. 5482 5483`scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5484 Passes if REGEX does not match demangled text in the dump file with 5485 suffix SUFFIX. 5486 54877.2.6.4 Verify that an output files exists or not 5488................................................. 5489 5490`output-exists [{ target/xfail SELECTOR }]' 5491 Passes if compiler output file exists. 5492 5493`output-exists-not [{ target/xfail SELECTOR }]' 5494 Passes if compiler output file does not exist. 5495 54967.2.6.5 Check for LTO tests 5497........................... 5498 5499`scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5500 Passes if the pattern is present in the final executable. 5501 55027.2.6.6 Checks for `gcov' tests 5503............................... 5504 5505`run-gcov SOURCEFILE' 5506 Check line counts in `gcov' tests. 5507 5508`run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5509 Check branch and/or call counts, in addition to line counts, in 5510 `gcov' tests. 5511 55127.2.6.7 Clean up generated test files 5513..................................... 5514 5515`cleanup-coverage-files' 5516 Removes coverage data files generated for this test. 5517 5518`cleanup-ipa-dump SUFFIX' 5519 Removes IPA dump files generated for this test. 5520 5521`cleanup-modules "LIST-OF-EXTRA-MODULES"' 5522 Removes Fortran module files generated for this test, excluding the 5523 module names listed in keep-modules. Cleaning up module files is 5524 usually done automatically by the testsuite by looking at the 5525 source files and removing the modules after the test has been 5526 executed. 5527 module MoD1 5528 end module MoD1 5529 module Mod2 5530 end module Mod2 5531 module moD3 5532 end module moD3 5533 module mod4 5534 end module mod4 5535 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5536 ! { dg-final { keep-modules "mod3 mod4" } } 5537 5538`keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5539 Whitespace separated list of module names that should not be 5540 deleted by cleanup-modules. If the list of modules is empty, all 5541 modules defined in this file are kept. 5542 module maybe_unneeded 5543 end module maybe_unneeded 5544 module keep1 5545 end module keep1 5546 module keep2 5547 end module keep2 5548 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5549 ! { dg-final { keep-modules "" } } ! keep all 5550 5551`cleanup-profile-file' 5552 Removes profiling files generated for this test. 5553 5554`cleanup-repo-files' 5555 Removes files generated for this test for `-frepo'. 5556 5557`cleanup-rtl-dump SUFFIX' 5558 Removes RTL dump files generated for this test. 5559 5560`cleanup-saved-temps' 5561 Removes files for the current test which were kept for 5562 `-save-temps'. 5563 5564`cleanup-tree-dump SUFFIX' 5565 Removes tree dump files matching SUFFIX which were generated for 5566 this test. 5567 5568 5569File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5570 55717.3 Ada Language Testsuites 5572=========================== 5573 5574The Ada testsuite includes executable tests from the ACATS testsuite, 5575publicly available at `http://www.ada-auth.org/acats.html'. 5576 5577 These tests are integrated in the GCC testsuite in the `ada/acats' 5578directory, and enabled automatically when running `make check', assuming 5579the Ada language has been enabled when configuring GCC. 5580 5581 You can also run the Ada testsuite independently, using `make 5582check-ada', or run a subset of the tests by specifying which chapter to 5583run, e.g.: 5584 5585 $ make check-ada CHAPTERS="c3 c9" 5586 5587 The tests are organized by directory, each directory corresponding to 5588a chapter of the Ada Reference Manual. So for example, `c9' corresponds 5589to chapter 9, which deals with tasking features of the language. 5590 5591 There is also an extra chapter called `gcc' containing a template for 5592creating new executable tests, although this is deprecated in favor of 5593the `gnat.dg' testsuite. 5594 5595 The tests are run using two `sh' scripts: `run_acats' and 5596`run_all.sh'. To run the tests using a simulator or a cross target, 5597see the small customization section at the top of `run_all.sh'. 5598 5599 These tests are run using the build tree: they can be run without doing 5600a `make install'. 5601 5602 5603File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 5604 56057.4 C Language Testsuites 5606========================= 5607 5608GCC contains the following C language testsuites, in the 5609`gcc/testsuite' directory: 5610 5611`gcc.dg' 5612 This contains tests of particular features of the C compiler, 5613 using the more modern `dg' harness. Correctness tests for various 5614 compiler features should go here if possible. 5615 5616 Magic comments determine whether the file is preprocessed, 5617 compiled, linked or run. In these tests, error and warning 5618 message texts are compared against expected texts or regular 5619 expressions given in comments. These tests are run with the 5620 options `-ansi -pedantic' unless other options are given in the 5621 test. Except as noted below they are not run with multiple 5622 optimization options. 5623 5624`gcc.dg/compat' 5625 This subdirectory contains tests for binary compatibility using 5626 `lib/compat.exp', which in turn uses the language-independent 5627 support (*note Support for testing binary compatibility: compat 5628 Testing.). 5629 5630`gcc.dg/cpp' 5631 This subdirectory contains tests of the preprocessor. 5632 5633`gcc.dg/debug' 5634 This subdirectory contains tests for debug formats. Tests in this 5635 subdirectory are run for each debug format that the compiler 5636 supports. 5637 5638`gcc.dg/format' 5639 This subdirectory contains tests of the `-Wformat' format 5640 checking. Tests in this directory are run with and without 5641 `-DWIDE'. 5642 5643`gcc.dg/noncompile' 5644 This subdirectory contains tests of code that should not compile 5645 and does not need any special compilation options. They are run 5646 with multiple optimization options, since sometimes invalid code 5647 crashes the compiler with optimization. 5648 5649`gcc.dg/special' 5650 FIXME: describe this. 5651 5652`gcc.c-torture' 5653 This contains particular code fragments which have historically 5654 broken easily. These tests are run with multiple optimization 5655 options, so tests for features which only break at some 5656 optimization levels belong here. This also contains tests to 5657 check that certain optimizations occur. It might be worthwhile to 5658 separate the correctness tests cleanly from the code quality 5659 tests, but it hasn't been done yet. 5660 5661`gcc.c-torture/compat' 5662 FIXME: describe this. 5663 5664 This directory should probably not be used for new tests. 5665 5666`gcc.c-torture/compile' 5667 This testsuite contains test cases that should compile, but do not 5668 need to link or run. These test cases are compiled with several 5669 different combinations of optimization options. All warnings are 5670 disabled for these test cases, so this directory is not suitable if 5671 you wish to test for the presence or absence of compiler warnings. 5672 While special options can be set, and tests disabled on specific 5673 platforms, by the use of `.x' files, mostly these test cases 5674 should not contain platform dependencies. FIXME: discuss how 5675 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used. 5676 5677`gcc.c-torture/execute' 5678 This testsuite contains test cases that should compile, link and 5679 run; otherwise the same comments as for `gcc.c-torture/compile' 5680 apply. 5681 5682`gcc.c-torture/execute/ieee' 5683 This contains tests which are specific to IEEE floating point. 5684 5685`gcc.c-torture/unsorted' 5686 FIXME: describe this. 5687 5688 This directory should probably not be used for new tests. 5689 5690`gcc.misc-tests' 5691 This directory contains C tests that require special handling. 5692 Some of these tests have individual expect files, and others share 5693 special-purpose expect files: 5694 5695 ``bprob*.c'' 5696 Test `-fbranch-probabilities' using 5697 `gcc.misc-tests/bprob.exp', which in turn uses the generic, 5698 language-independent framework (*note Support for testing 5699 profile-directed optimizations: profopt Testing.). 5700 5701 ``gcov*.c'' 5702 Test `gcov' output using `gcov.exp', which in turn uses the 5703 language-independent support (*note Support for testing gcov: 5704 gcov Testing.). 5705 5706 ``i386-pf-*.c'' 5707 Test i386-specific support for data prefetch using 5708 `i386-prefetch.exp'. 5709 5710`gcc.test-framework' 5711 5712 ``dg-*.c'' 5713 Test the testsuite itself using 5714 `gcc.test-framework/test-framework.exp'. 5715 5716 5717 FIXME: merge in `testsuite/README.gcc' and discuss the format of test 5718cases and magic comments more. 5719 5720 5721File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites 5722 57237.5 The Java library testsuites. 5724================================ 5725 5726Runtime tests are executed via `make check' in the 5727`TARGET/libjava/testsuite' directory in the build tree. Additional 5728runtime tests can be checked into this testsuite. 5729 5730 Regression testing of the core packages in libgcj is also covered by 5731the Mauve testsuite. The Mauve Project develops tests for the Java 5732Class Libraries. These tests are run as part of libgcj testing by 5733placing the Mauve tree within the libjava testsuite sources at 5734`libjava/testsuite/libjava.mauve/mauve', or by specifying the location 5735of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'. 5736 5737 To detect regressions, a mechanism in `mauve.exp' compares the 5738failures for a test run against the list of expected failures in 5739`libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 5740Update this file when adding new failing tests to Mauve, or when fixing 5741bugs in libgcj that had caused Mauve test failures. 5742 5743 We encourage developers to contribute test cases to Mauve. 5744 5745 5746File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites 5747 57487.6 Support for testing link-time optimizations 5749=============================================== 5750 5751Tests for link-time optimizations usually require multiple source files 5752that are compiled separately, perhaps with different sets of options. 5753There are several special-purpose test directives used for these tests. 5754 5755`{ dg-lto-do DO-WHAT-KEYWORD }' 5756 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 5757 is executed. It is one of: 5758 5759 `assemble' 5760 Compile with `-c' to produce a relocatable object file. 5761 5762 `link' 5763 Compile, assemble, and link to produce an executable file. 5764 5765 `run' 5766 Produce and run an executable file, which is expected to 5767 return an exit code of 0. 5768 5769 The default is `assemble'. That can be overridden for a set of 5770 tests by redefining `dg-do-what-default' within the `.exp' file 5771 for those tests. 5772 5773 Unlike `dg-do', `dg-lto-do' does not support an optional `target' 5774 or `xfail' list. Use `dg-skip-if', `dg-xfail-if', or 5775 `dg-xfail-run-if'. 5776 5777`{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 5778 This directive provides a list of one or more sets of compiler 5779 options to override LTO_OPTIONS. Each test will be compiled and 5780 run with each of these sets of options. 5781 5782`{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 5783 This directive adds OPTIONS to the linker options used. 5784 5785`{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 5786 This directive removes OPTIONS from the set of linker options used. 5787 5788 5789File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 5790 57917.7 Support for testing `gcov' 5792============================== 5793 5794Language-independent support for testing `gcov', and for checking that 5795branch profiling produces expected values, is provided by the expect 5796file `lib/gcov.exp'. `gcov' tests also rely on procedures in 5797`lib/gcc-dg.exp' to compile and run the test program. A typical `gcov' 5798test contains the following DejaGnu commands within comments: 5799 5800 { dg-options "-fprofile-arcs -ftest-coverage" } 5801 { dg-do run { target native } } 5802 { dg-final { run-gcov sourcefile } } 5803 5804 Checks of `gcov' output can include line counts, branch percentages, 5805and call return percentages. All of these checks are requested via 5806commands that appear in comments in the test's source file. Commands 5807to check line counts are processed by default. Commands to check 5808branch percentages and call return percentages are processed if the 5809`run-gcov' command has arguments `branches' or `calls', respectively. 5810For example, the following specifies checking both, as well as passing 5811`-b' to `gcov': 5812 5813 { dg-final { run-gcov branches calls { -b sourcefile } } } 5814 5815 A line count command appears within a comment on the source line that 5816is expected to get the specified count and has the form `count(CNT)'. 5817A test should only check line counts for lines that will get the same 5818count for any architecture. 5819 5820 Commands to check branch percentages (`branch') and call return 5821percentages (`returns') are very similar to each other. A beginning 5822command appears on or before the first of a range of lines that will 5823report the percentage, and the ending command follows that range of 5824lines. The beginning command can include a list of percentages, all of 5825which are expected to be found within the range. A range is terminated 5826by the next command of the same kind. A command `branch(end)' or 5827`returns(end)' marks the end of a range without starting a new one. 5828For example: 5829 5830 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 5831 /* branch(end) */ 5832 foo (i, j); 5833 5834 For a call return percentage, the value specified is the percentage of 5835calls reported to return. For a branch percentage, the value is either 5836the expected percentage or 100 minus that value, since the direction of 5837a branch can differ depending on the target or the optimization level. 5838 5839 Not all branches and calls need to be checked. A test should not 5840check for branches that might be optimized away or replaced with 5841predicated instructions. Don't check for calls inserted by the 5842compiler or ones that might be inlined or optimized away. 5843 5844 A single test can check for combinations of line counts, branch 5845percentages, and call return percentages. The command to check a line 5846count must appear on the line that will report that count, but commands 5847to check branch percentages and call return percentages can bracket the 5848lines that report them. 5849 5850 5851File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 5852 58537.8 Support for testing profile-directed optimizations 5854====================================================== 5855 5856The file `profopt.exp' provides language-independent support for 5857checking correct execution of a test built with profile-directed 5858optimization. This testing requires that a test program be built and 5859executed twice. The first time it is compiled to generate profile 5860data, and the second time it is compiled to use the data that was 5861generated during the first execution. The second execution is to 5862verify that the test produces the expected results. 5863 5864 To check that the optimization actually generated better code, a test 5865can be built and run a third time with normal optimizations to verify 5866that the performance is better with the profile-directed optimizations. 5867`profopt.exp' has the beginnings of this kind of support. 5868 5869 `profopt.exp' provides generic support for profile-directed 5870optimizations. Each set of tests that uses it provides information 5871about a specific optimization: 5872 5873`tool' 5874 tool being tested, e.g., `gcc' 5875 5876`profile_option' 5877 options used to generate profile data 5878 5879`feedback_option' 5880 options used to optimize using that profile data 5881 5882`prof_ext' 5883 suffix of profile data files 5884 5885`PROFOPT_OPTIONS' 5886 list of options with which to run each test, similar to the lists 5887 for torture tests 5888 5889`{ dg-final-generate { LOCAL-DIRECTIVE } }' 5890 This directive is similar to `dg-final', but the LOCAL-DIRECTIVE 5891 is run after the generation of profile data. 5892 5893`{ dg-final-use { LOCAL-DIRECTIVE } }' 5894 The LOCAL-DIRECTIVE is run after the profile data have been used. 5895 5896 5897File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 5898 58997.9 Support for testing binary compatibility 5900============================================ 5901 5902The file `compat.exp' provides language-independent support for binary 5903compatibility testing. It supports testing interoperability of two 5904compilers that follow the same ABI, or of multiple sets of compiler 5905options that should not affect binary compatibility. It is intended to 5906be used for testsuites that complement ABI testsuites. 5907 5908 A test supported by this framework has three parts, each in a separate 5909source file: a main program and two pieces that interact with each 5910other to split up the functionality being tested. 5911 5912`TESTNAME_main.SUFFIX' 5913 Contains the main program, which calls a function in file 5914 `TESTNAME_x.SUFFIX'. 5915 5916`TESTNAME_x.SUFFIX' 5917 Contains at least one call to a function in `TESTNAME_y.SUFFIX'. 5918 5919`TESTNAME_y.SUFFIX' 5920 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'. 5921 5922 Within each test, the main program and one functional piece are 5923compiled by the GCC under test. The other piece can be compiled by an 5924alternate compiler. If no alternate compiler is specified, then all 5925three source files are all compiled by the GCC under test. You can 5926specify pairs of sets of compiler options. The first element of such a 5927pair specifies options used with the GCC under test, and the second 5928element of the pair specifies options used with the alternate compiler. 5929Each test is compiled with each pair of options. 5930 5931 `compat.exp' defines default pairs of compiler options. These can be 5932overridden by defining the environment variable `COMPAT_OPTIONS' as: 5933 5934 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 5935 ...[list {TSTN} {ALTN}]]" 5936 5937 where TSTI and ALTI are lists of options, with TSTI used by the 5938compiler under test and ALTI used by the alternate compiler. For 5939example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 5940the test is first built with `-g -O0' by the compiler under test and 5941with `-O3' by the alternate compiler. The test is built a second time 5942using `-fpic' by the compiler under test and `-fPIC -O2' by the 5943alternate compiler. 5944 5945 An alternate compiler is specified by defining an environment variable 5946to be the full pathname of an installed compiler; for C define 5947`ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These 5948will be written to the `site.exp' file used by DejaGnu. The default is 5949to build each test with the compiler under test using the first of each 5950pair of compiler options from `COMPAT_OPTIONS'. When 5951`ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is 5952built using the compiler under test but with combinations of the 5953options from `COMPAT_OPTIONS'. 5954 5955 To run only the C++ compatibility suite using the compiler under test 5956and another version of GCC using specific compiler options, do the 5957following from `OBJDIR/gcc': 5958 5959 rm site.exp 5960 make -k \ 5961 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 5962 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 5963 check-c++ \ 5964 RUNTESTFLAGS="compat.exp" 5965 5966 A test that fails when the source files are compiled with different 5967compilers, but passes when the files are compiled with the same 5968compiler, demonstrates incompatibility of the generated code or runtime 5969support. A test that fails for the alternate compiler but passes for 5970the compiler under test probably tests for a bug that was fixed in the 5971compiler under test but is present in the alternate compiler. 5972 5973 The binary compatibility tests support a small number of test framework 5974commands that appear within comments in a test file. 5975 5976`dg-require-*' 5977 These commands can be used in `TESTNAME_main.SUFFIX' to skip the 5978 test if specific support is not available on the target. 5979 5980`dg-options' 5981 The specified options are used for compiling this particular source 5982 file, appended to the options from `COMPAT_OPTIONS'. When this 5983 command appears in `TESTNAME_main.SUFFIX' the options are also 5984 used to link the test program. 5985 5986`dg-xfail-if' 5987 This command can be used in a secondary source file to specify that 5988 compilation is expected to fail for particular options on 5989 particular targets. 5990 5991 5992File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites 5993 59947.10 Support for torture testing using multiple options 5995======================================================= 5996 5997Throughout the compiler testsuite there are several directories whose 5998tests are run multiple times, each with a different set of options. 5999These are known as torture tests. `lib/torture-options.exp' defines 6000procedures to set up these lists: 6001 6002`torture-init' 6003 Initialize use of torture lists. 6004 6005`set-torture-options' 6006 Set lists of torture options to use for tests with and without 6007 loops. Optionally combine a set of torture options with a set of 6008 other options, as is done with Objective-C runtime options. 6009 6010`torture-finish' 6011 Finalize use of torture lists. 6012 6013 The `.exp' file for a set of tests that use torture options must 6014include calls to these three procedures if: 6015 6016 * It calls `gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6017 6018 * It calls ${TOOL}`-torture' or ${TOOL}`-torture-execute', where 6019 TOOL is `c', `fortran', or `objc'. 6020 6021 * It calls `dg-pch'. 6022 6023 It is not necessary for a `.exp' file that calls `gcc-dg-runtest' to 6024call the torture procedures if the tests should use the list in 6025DG_TORTURE_OPTIONS defined in `gcc-dg.exp'. 6026 6027 Most uses of torture options can override the default lists by defining 6028TORTURE_OPTIONS or add to the default list by defining 6029ADDITIONAL_TORTURE_OPTIONS. Define these in a `.dejagnurc' file or add 6030them to the `site.exp' file; for example 6031 6032 set ADDITIONAL_TORTURE_OPTIONS [list \ 6033 { -O2 -ftree-loop-linear } \ 6034 { -O2 -fpeel-loops } ] 6035 6036 6037File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6038 60398 Option specification files 6040**************************** 6041 6042Most GCC command-line options are described by special option 6043definition files, the names of which conventionally end in `.opt'. 6044This chapter describes the format of these files. 6045 6046* Menu: 6047 6048* Option file format:: The general layout of the files 6049* Option properties:: Supported option properties 6050 6051 6052File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6053 60548.1 Option file format 6055====================== 6056 6057Option files are a simple list of records in which each field occupies 6058its own line and in which the records themselves are separated by blank 6059lines. Comments may appear on their own line anywhere within the file 6060and are preceded by semicolons. Whitespace is allowed before the 6061semicolon. 6062 6063 The files can contain the following types of record: 6064 6065 * A language definition record. These records have two fields: the 6066 string `Language' and the name of the language. Once a language 6067 has been declared in this way, it can be used as an option 6068 property. *Note Option properties::. 6069 6070 * A target specific save record to save additional information. These 6071 records have two fields: the string `TargetSave', and a 6072 declaration type to go in the `cl_target_option' structure. 6073 6074 * A variable record to define a variable used to store option 6075 information. These records have two fields: the string 6076 `Variable', and a declaration of the type and name of the 6077 variable, optionally with an initializer (but without any trailing 6078 `;'). These records may be used for variables used for many 6079 options where declaring the initializer in a single option 6080 definition record, or duplicating it in many records, would be 6081 inappropriate, or for variables set in option handlers rather than 6082 referenced by `Var' properties. 6083 6084 * A variable record to define a variable used to store option 6085 information. These records have two fields: the string 6086 `TargetVariable', and a declaration of the type and name of the 6087 variable, optionally with an initializer (but without any trailing 6088 `;'). `TargetVariable' is a combination of `Variable' and 6089 `TargetSave' records in that the variable is defined in the 6090 `gcc_options' structure, but these variables are also stored in 6091 the `cl_target_option' structure. The variables are saved in the 6092 target save code and restored in the target restore code. 6093 6094 * A variable record to record any additional files that the 6095 `options.h' file should include. This is useful to provide 6096 enumeration or structure definitions needed for target variables. 6097 These records have two fields: the string `HeaderInclude' and the 6098 name of the include file. 6099 6100 * A variable record to record any additional files that the 6101 `options.c' or `options-save.c' file should include. This is 6102 useful to provide inline functions needed for target variables 6103 and/or `#ifdef' sequences to properly set up the initialization. 6104 These records have two fields: the string `SourceInclude' and the 6105 name of the include file. 6106 6107 * An enumeration record to define a set of strings that may be used 6108 as arguments to an option or options. These records have three 6109 fields: the string `Enum', a space-separated list of properties 6110 and help text used to describe the set of strings in `--help' 6111 output. Properties use the same format as option properties; the 6112 following are valid: 6113 `Name(NAME)' 6114 This property is required; NAME must be a name (suitable for 6115 use in C identifiers) used to identify the set of strings in 6116 `Enum' option properties. 6117 6118 `Type(TYPE)' 6119 This property is required; TYPE is the C type for variables 6120 set by options using this enumeration together with `Var'. 6121 6122 `UnknownError(MESSAGE)' 6123 The message MESSAGE will be used as an error message if the 6124 argument is invalid; for enumerations without `UnknownError', 6125 a generic error message is used. MESSAGE should contain a 6126 single `%qs' format, which will be used to format the invalid 6127 argument. 6128 6129 * An enumeration value record to define one of the strings in a set 6130 given in an `Enum' record. These records have two fields: the 6131 string `EnumValue' and a space-separated list of properties. 6132 Properties use the same format as option properties; the following 6133 are valid: 6134 `Enum(NAME)' 6135 This property is required; NAME says which `Enum' record this 6136 `EnumValue' record corresponds to. 6137 6138 `String(STRING)' 6139 This property is required; STRING is the string option 6140 argument being described by this record. 6141 6142 `Value(VALUE)' 6143 This property is required; it says what value (representable 6144 as `int') should be used for the given string. 6145 6146 `Canonical' 6147 This property is optional. If present, it says the present 6148 string is the canonical one among all those with the given 6149 value. Other strings yielding that value will be mapped to 6150 this one so specs do not need to handle them. 6151 6152 `DriverOnly' 6153 This property is optional. If present, the present string 6154 will only be accepted by the driver. This is used for cases 6155 such as `-march=native' that are processed by the driver so 6156 that `gcc -v' shows how the options chosen depended on the 6157 system on which the compiler was run. 6158 6159 * An option definition record. These records have the following 6160 fields: 6161 1. the name of the option, with the leading "-" removed 6162 6163 2. a space-separated list of option properties (*note Option 6164 properties::) 6165 6166 3. the help text to use for `--help' (omitted if the second field 6167 contains the `Undocumented' property). 6168 6169 By default, all options beginning with "f", "W" or "m" are 6170 implicitly assumed to take a "no-" form. This form should not be 6171 listed separately. If an option beginning with one of these 6172 letters does not have a "no-" form, you can use the 6173 `RejectNegative' property to reject it. 6174 6175 The help text is automatically line-wrapped before being displayed. 6176 Normally the name of the option is printed on the left-hand side of 6177 the output and the help text is printed on the right. However, if 6178 the help text contains a tab character, the text to the left of 6179 the tab is used instead of the option's name and the text to the 6180 right of the tab forms the help text. This allows you to 6181 elaborate on what type of argument the option takes. 6182 6183 * A target mask record. These records have one field of the form 6184 `Mask(X)'. The options-processing script will automatically 6185 allocate a bit in `target_flags' (*note Run-time Target::) for 6186 each mask name X and set the macro `MASK_X' to the appropriate 6187 bitmask. It will also declare a `TARGET_X' macro that has the 6188 value 1 when bit `MASK_X' is set and 0 otherwise. 6189 6190 They are primarily intended to declare target masks that are not 6191 associated with user options, either because these masks represent 6192 internal switches or because the options are not available on all 6193 configurations and yet the masks always need to be defined. 6194 6195 6196File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6197 61988.2 Option properties 6199===================== 6200 6201The second field of an option record can specify any of the following 6202properties. When an option takes an argument, it is enclosed in 6203parentheses following the option property name. The parser that 6204handles option files is quite simplistic, and will be tricked by any 6205nested parentheses within the argument text itself; in this case, the 6206entire option argument can be wrapped in curly braces within the 6207parentheses to demarcate it, e.g.: 6208 6209 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6210 6211`Common' 6212 The option is available for all languages and targets. 6213 6214`Target' 6215 The option is available for all languages but is target-specific. 6216 6217`Driver' 6218 The option is handled by the compiler driver using code not shared 6219 with the compilers proper (`cc1' etc.). 6220 6221`LANGUAGE' 6222 The option is available when compiling for the given language. 6223 6224 It is possible to specify several different languages for the same 6225 option. Each LANGUAGE must have been declared by an earlier 6226 `Language' record. *Note Option file format::. 6227 6228`RejectDriver' 6229 The option is only handled by the compilers proper (`cc1' etc.) 6230 and should not be accepted by the driver. 6231 6232`RejectNegative' 6233 The option does not have a "no-" form. All options beginning with 6234 "f", "W" or "m" are assumed to have a "no-" form unless this 6235 property is used. 6236 6237`Negative(OTHERNAME)' 6238 The option will turn off another option OTHERNAME, which is the 6239 option name with the leading "-" removed. This chain action will 6240 propagate through the `Negative' property of the option to be 6241 turned off. 6242 6243 As a consequence, if you have a group of mutually-exclusive 6244 options, their `Negative' properties should form a circular chain. 6245 For example, if options `-A', `-B' and `-C' are mutually 6246 exclusive, their respective `Negative' properties should be 6247 `Negative(B)', `Negative(C)' and `Negative(A)'. 6248 6249`Joined' 6250`Separate' 6251 The option takes a mandatory argument. `Joined' indicates that 6252 the option and argument can be included in the same `argv' entry 6253 (as with `-mflush-func=NAME', for example). `Separate' indicates 6254 that the option and argument can be separate `argv' entries (as 6255 with `-o'). An option is allowed to have both of these properties. 6256 6257`JoinedOrMissing' 6258 The option takes an optional argument. If the argument is given, 6259 it will be part of the same `argv' entry as the option itself. 6260 6261 This property cannot be used alongside `Joined' or `Separate'. 6262 6263`MissingArgError(MESSAGE)' 6264 For an option marked `Joined' or `Separate', the message MESSAGE 6265 will be used as an error message if the mandatory argument is 6266 missing; for options without `MissingArgError', a generic error 6267 message is used. MESSAGE should contain a single `%qs' format, 6268 which will be used to format the name of the option passed. 6269 6270`Args(N)' 6271 For an option marked `Separate', indicate that it takes N 6272 arguments. The default is 1. 6273 6274`UInteger' 6275 The option's argument is a non-negative integer. The option parser 6276 will check and convert the argument before passing it to the 6277 relevant option handler. `UInteger' should also be used on 6278 options like `-falign-loops' where both `-falign-loops' and 6279 `-falign-loops'=N are supported to make sure the saved options are 6280 given a full integer. 6281 6282`ToLower' 6283 The option's argument should be converted to lowercase as part of 6284 putting it in canonical form, and before comparing with the strings 6285 indicated by any `Enum' property. 6286 6287`NoDriverArg' 6288 For an option marked `Separate', the option only takes an argument 6289 in the compiler proper, not in the driver. This is for 6290 compatibility with existing options that are used both directly and 6291 via `-Wp,'; new options should not have this property. 6292 6293`Var(VAR)' 6294 The state of this option should be stored in variable VAR 6295 (actually a macro for `global_options.x_VAR'). The way that the 6296 state is stored depends on the type of option: 6297 6298 * If the option uses the `Mask' or `InverseMask' properties, 6299 VAR is the integer variable that contains the mask. 6300 6301 * If the option is a normal on/off switch, VAR is an integer 6302 variable that is nonzero when the option is enabled. The 6303 options parser will set the variable to 1 when the positive 6304 form of the option is used and 0 when the "no-" form is used. 6305 6306 * If the option takes an argument and has the `UInteger' 6307 property, VAR is an integer variable that stores the value of 6308 the argument. 6309 6310 * If the option takes an argument and has the `Enum' property, 6311 VAR is a variable (type given in the `Type' property of the 6312 `Enum' record whose `Name' property has the same argument as 6313 the `Enum' property of this option) that stores the value of 6314 the argument. 6315 6316 * If the option has the `Defer' property, VAR is a pointer to a 6317 `VEC(cl_deferred_option,heap)' that stores the option for 6318 later processing. (VAR is declared with type `void *' and 6319 needs to be cast to `VEC(cl_deferred_option,heap)' before 6320 use.) 6321 6322 * Otherwise, if the option takes an argument, VAR is a pointer 6323 to the argument string. The pointer will be null if the 6324 argument is optional and wasn't given. 6325 6326 The option-processing script will usually zero-initialize VAR. 6327 You can modify this behavior using `Init'. 6328 6329`Var(VAR, SET)' 6330 The option controls an integer variable VAR and is active when VAR 6331 equals SET. The option parser will set VAR to SET when the 6332 positive form of the option is used and `!SET' when the "no-" form 6333 is used. 6334 6335 VAR is declared in the same way as for the single-argument form 6336 described above. 6337 6338`Init(VALUE)' 6339 The variable specified by the `Var' property should be statically 6340 initialized to VALUE. If more than one option using the same 6341 variable specifies `Init', all must specify the same initializer. 6342 6343`Mask(NAME)' 6344 The option is associated with a bit in the `target_flags' variable 6345 (*note Run-time Target::) and is active when that bit is set. You 6346 may also specify `Var' to select a variable other than 6347 `target_flags'. 6348 6349 The options-processing script will automatically allocate a unique 6350 bit for the option. If the option is attached to `target_flags', 6351 the script will set the macro `MASK_NAME' to the appropriate 6352 bitmask. It will also declare a `TARGET_NAME' macro that has the 6353 value 1 when the option is active and 0 otherwise. If you use 6354 `Var' to attach the option to a different variable, the bitmask 6355 macro with be called `OPTION_MASK_NAME'. 6356 6357`InverseMask(OTHERNAME)' 6358`InverseMask(OTHERNAME, THISNAME)' 6359 The option is the inverse of another option that has the 6360 `Mask(OTHERNAME)' property. If THISNAME is given, the 6361 options-processing script will declare a `TARGET_THISNAME' macro 6362 that is 1 when the option is active and 0 otherwise. 6363 6364`Enum(NAME)' 6365 The option's argument is a string from the set of strings 6366 associated with the corresponding `Enum' record. The string is 6367 checked and converted to the integer specified in the corresponding 6368 `EnumValue' record before being passed to option handlers. 6369 6370`Defer' 6371 The option should be stored in a vector, specified with `Var', for 6372 later processing. 6373 6374`Alias(OPT)' 6375`Alias(OPT, ARG)' 6376`Alias(OPT, POSARG, NEGARG)' 6377 The option is an alias for `-OPT' (or the negative form of that 6378 option, depending on `NegativeAlias'). In the first form, any 6379 argument passed to the alias is considered to be passed to `-OPT', 6380 and `-OPT' is considered to be negated if the alias is used in 6381 negated form. In the second form, the alias may not be negated or 6382 have an argument, and POSARG is considered to be passed as an 6383 argument to `-OPT'. In the third form, the alias may not have an 6384 argument, if the alias is used in the positive form then POSARG is 6385 considered to be passed to `-OPT', and if the alias is used in the 6386 negative form then NEGARG is considered to be passed to `-OPT'. 6387 6388 Aliases should not specify `Var' or `Mask' or `UInteger'. Aliases 6389 should normally specify the same languages as the target of the 6390 alias; the flags on the target will be used to determine any 6391 diagnostic for use of an option for the wrong language, while 6392 those on the alias will be used to identify what command-line text 6393 is the option and what text is any argument to that option. 6394 6395 When an `Alias' definition is used for an option, driver specs do 6396 not need to handle it and no `OPT_' enumeration value is defined 6397 for it; only the canonical form of the option will be seen in those 6398 places. 6399 6400`NegativeAlias' 6401 For an option marked with `Alias(OPT)', the option is considered 6402 to be an alias for the positive form of `-OPT' if negated and for 6403 the negative form of `-OPT' if not negated. `NegativeAlias' may 6404 not be used with the forms of `Alias' taking more than one 6405 argument. 6406 6407`Ignore' 6408 This option is ignored apart from printing any warning specified 6409 using `Warn'. The option will not be seen by specs and no `OPT_' 6410 enumeration value is defined for it. 6411 6412`SeparateAlias' 6413 For an option marked with `Joined', `Separate' and `Alias', the 6414 option only acts as an alias when passed a separate argument; with 6415 a joined argument it acts as a normal option, with an `OPT_' 6416 enumeration value. This is for compatibility with the Java `-d' 6417 option and should not be used for new options. 6418 6419`Warn(MESSAGE)' 6420 If this option is used, output the warning MESSAGE. MESSAGE is a 6421 format string, either taking a single operand with a `%qs' format 6422 which is the option name, or not taking any operands, which is 6423 passed to the `warning' function. If an alias is marked `Warn', 6424 the target of the alias must not also be marked `Warn'. 6425 6426`Report' 6427 The state of the option should be printed by `-fverbose-asm'. 6428 6429`Warning' 6430 This is a warning option and should be shown as such in `--help' 6431 output. This flag does not currently affect anything other than 6432 `--help'. 6433 6434`Optimization' 6435 This is an optimization option. It should be shown as such in 6436 `--help' output, and any associated variable named using `Var' 6437 should be saved and restored when the optimization level is 6438 changed with `optimize' attributes. 6439 6440`Undocumented' 6441 The option is deliberately missing documentation and should not be 6442 included in the `--help' output. 6443 6444`Condition(COND)' 6445 The option should only be accepted if preprocessor condition COND 6446 is true. Note that any C declarations associated with the option 6447 will be present even if COND is false; COND simply controls 6448 whether the option is accepted and whether it is printed in the 6449 `--help' output. 6450 6451`Save' 6452 Build the `cl_target_option' structure to hold a copy of the 6453 option, add the functions `cl_target_option_save' and 6454 `cl_target_option_restore' to save and restore the options. 6455 6456`SetByCombined' 6457 The option may also be set by a combined option such as 6458 `-ffast-math'. This causes the `gcc_options' struct to have a 6459 field `frontend_set_NAME', where `NAME' is the name of the field 6460 holding the value of this option (without the leading `x_'). This 6461 gives the front end a way to indicate that the value has been set 6462 explicitly and should not be changed by the combined option. For 6463 example, some front ends use this to prevent `-ffast-math' and 6464 `-fno-fast-math' from changing the value of `-fmath-errno' for 6465 languages that do not use `errno'. 6466 6467`EnabledBy(OPT)' 6468`EnabledBy(OPT && OPT2)' 6469 If not explicitly set, the option is set to the value of `-OPT'. 6470 The second form specifies that the option is only set if both OPT 6471 and OPT2 are set. 6472 6473`LangEnabledBy(LANGUAGE, OPT)' 6474`LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 6475 When compiling for the given language, the option is set to the 6476 value of `-OPT', if not explicitly set. In the second form, if OPT 6477 is used in the positive form then POSARG is considered to be 6478 passed to the option, and if OPT is used in the negative form then 6479 NEGARG is considered to be passed to the option. It is possible 6480 to specify several different languages. Each LANGUAGE must have 6481 been declared by an earlier `Language' record. *Note Option file 6482 format::. 6483 6484`NoDWARFRecord' 6485 The option is omitted from the producer string written by 6486 `-grecord-gcc-switches'. 6487 6488 6489File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top 6490 64919 Passes and Files of the Compiler 6492********************************** 6493 6494This chapter is dedicated to giving an overview of the optimization and 6495code generation passes of the compiler. In the process, it describes 6496some of the language front end interface, though this description is no 6497where near complete. 6498 6499* Menu: 6500 6501* Parsing pass:: The language front end turns text into bits. 6502* Gimplification pass:: The bits are turned into something we can optimize. 6503* Pass manager:: Sequencing the optimization passes. 6504* Tree SSA passes:: Optimizations on a high-level representation. 6505* RTL passes:: Optimizations on a low-level representation. 6506 6507 6508File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 6509 65109.1 Parsing pass 6511================ 6512 6513The language front end is invoked only once, via 6514`lang_hooks.parse_file', to parse the entire input. The language front 6515end may use any intermediate language representation deemed 6516appropriate. The C front end uses GENERIC trees (*note GENERIC::), plus 6517a double handful of language specific tree codes defined in 6518`c-common.def'. The Fortran front end uses a completely different 6519private representation. 6520 6521 At some point the front end must translate the representation used in 6522the front end to a representation understood by the language-independent 6523portions of the compiler. Current practice takes one of two forms. 6524The C front end manually invokes the gimplifier (*note GIMPLE::) on 6525each function, and uses the gimplifier callbacks to convert the 6526language-specific tree nodes directly to GIMPLE before passing the 6527function off to be compiled. The Fortran front end converts from a 6528private representation to GENERIC, which is later lowered to GIMPLE 6529when the function is compiled. Which route to choose probably depends 6530on how well GENERIC (plus extensions) can be made to match up with the 6531source language and necessary parsing data structures. 6532 6533 BUG: Gimplification must occur before nested function lowering, and 6534nested function lowering must be done by the front end before passing 6535the data off to cgraph. 6536 6537 TODO: Cgraph should control nested function lowering. It would only 6538be invoked when it is certain that the outer-most function is used. 6539 6540 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6541when (1) it is certain that the function is used, (2) warning flags 6542specified by the user require some amount of compilation in order to 6543honor, (3) the language indicates that semantic analysis is not 6544complete until gimplification occurs. Hum... this sounds overly 6545complicated. Perhaps we should just have the front end gimplify 6546always; in most cases it's only one function call. 6547 6548 The front end needs to pass all function definitions and top level 6549declarations off to the middle-end so that they can be compiled and 6550emitted to the object file. For a simple procedural language, it is 6551usually most convenient to do this as each top level declaration or 6552definition is seen. There is also a distinction to be made between 6553generating functional code and generating complete debug information. 6554The only thing that is absolutely required for functional code is that 6555function and data _definitions_ be passed to the middle-end. For 6556complete debug information, function, data and type declarations should 6557all be passed as well. 6558 6559 In any case, the front end needs each complete top-level function or 6560data declaration, and each data definition should be passed to 6561`rest_of_decl_compilation'. Each complete type definition should be 6562passed to `rest_of_type_compilation'. Each function definition should 6563be passed to `cgraph_finalize_function'. 6564 6565 TODO: I know rest_of_compilation currently has all sorts of RTL 6566generation semantics. I plan to move all code generation bits (both 6567Tree and RTL) to compile_function. Should we hide cgraph from the 6568front ends and move back to rest_of_compilation as the official 6569interface? Possibly we should rename all three interfaces such that 6570the names match in some meaningful way and that is more descriptive 6571than "rest_of". 6572 6573 The middle-end will, at its option, emit the function and data 6574definitions immediately or queue them for later processing. 6575 6576 6577File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 6578 65799.2 Gimplification pass 6580======================= 6581 6582"Gimplification" is a whimsical term for the process of converting the 6583intermediate representation of a function into the GIMPLE language 6584(*note GIMPLE::). The term stuck, and so words like "gimplification", 6585"gimplify", "gimplifier" and the like are sprinkled throughout this 6586section of code. 6587 6588 While a front end may certainly choose to generate GIMPLE directly if 6589it chooses, this can be a moderately complex process unless the 6590intermediate language used by the front end is already fairly simple. 6591Usually it is easier to generate GENERIC trees plus extensions and let 6592the language-independent gimplifier do most of the work. 6593 6594 The main entry point to this pass is `gimplify_function_tree' located 6595in `gimplify.c'. From here we process the entire function gimplifying 6596each statement in turn. The main workhorse for this pass is 6597`gimplify_expr'. Approximately everything passes through here at least 6598once, and it is from here that we invoke the `lang_hooks.gimplify_expr' 6599callback. 6600 6601 The callback should examine the expression in question and return 6602`GS_UNHANDLED' if the expression is not a language specific construct 6603that requires attention. Otherwise it should alter the expression in 6604some way to such that forward progress is made toward producing valid 6605GIMPLE. If the callback is certain that the transformation is complete 6606and the expression is valid GIMPLE, it should return `GS_ALL_DONE'. 6607Otherwise it should return `GS_OK', which will cause the expression to 6608be processed again. If the callback encounters an error during the 6609transformation (because the front end is relying on the gimplification 6610process to finish semantic checks), it should return `GS_ERROR'. 6611 6612 6613File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 6614 66159.3 Pass manager 6616================ 6617 6618The pass manager is located in `passes.c', `tree-optimize.c' and 6619`tree-pass.h'. Its job is to run all of the individual passes in the 6620correct order, and take care of standard bookkeeping that applies to 6621every pass. 6622 6623 The theory of operation is that each pass defines a structure that 6624represents everything we need to know about that pass--when it should 6625be run, how it should be run, what intermediate language form or 6626on-the-side data structures it needs. We register the pass to be run 6627in some particular order, and the pass manager arranges for everything 6628to happen in the correct order. 6629 6630 The actuality doesn't completely live up to the theory at present. 6631Command-line switches and `timevar_id_t' enumerations must still be 6632defined elsewhere. The pass manager validates constraints but does not 6633attempt to (re-)generate data structures or lower intermediate language 6634form based on the requirements of the next pass. Nevertheless, what is 6635present is useful, and a far sight better than nothing at all. 6636 6637 Each pass should have a unique name. Each pass may have its own dump 6638file (for GCC debugging purposes). Passes with a name starting with a 6639star do not dump anything. Sometimes passes are supposed to share a 6640dump file / option name. To still give these unique names, you can use 6641a prefix that is delimited by a space from the part that is used for 6642the dump file / option name. E.g. When the pass name is "ud dce", the 6643name used for dump file/options is "dce". 6644 6645 TODO: describe the global variables set up by the pass manager, and a 6646brief description of how a new pass should use it. I need to look at 6647what info RTL passes use first... 6648 6649 6650File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 6651 66529.4 Tree SSA passes 6653=================== 6654 6655The following briefly describes the Tree optimization passes that are 6656run after gimplification and what source files they are located in. 6657 6658 * Remove useless statements 6659 6660 This pass is an extremely simple sweep across the gimple code in 6661 which we identify obviously dead code and remove it. Here we do 6662 things like simplify `if' statements with constant conditions, 6663 remove exception handling constructs surrounding code that 6664 obviously cannot throw, remove lexical bindings that contain no 6665 variables, and other assorted simplistic cleanups. The idea is to 6666 get rid of the obvious stuff quickly rather than wait until later 6667 when it's more work to get rid of it. This pass is located in 6668 `tree-cfg.c' and described by `pass_remove_useless_stmts'. 6669 6670 * Mudflap declaration registration 6671 6672 If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize 6673 Options.) is enabled, we generate code to register some variable 6674 declarations with the mudflap runtime. Specifically, the runtime 6675 tracks the lifetimes of those variable declarations that have 6676 their addresses taken, or whose bounds are unknown at compile time 6677 (`extern'). This pass generates new exception handling constructs 6678 (`try'/`finally'), and so must run before those are lowered. In 6679 addition, the pass enqueues declarations of static variables whose 6680 lifetimes extend to the entire program. The pass is located in 6681 `tree-mudflap.c' and is described by `pass_mudflap_1'. 6682 6683 * OpenMP lowering 6684 6685 If OpenMP generation (`-fopenmp') is enabled, this pass lowers 6686 OpenMP constructs into GIMPLE. 6687 6688 Lowering of OpenMP constructs involves creating replacement 6689 expressions for local variables that have been mapped using data 6690 sharing clauses, exposing the control flow of most synchronization 6691 directives and adding region markers to facilitate the creation of 6692 the control flow graph. The pass is located in `omp-low.c' and is 6693 described by `pass_lower_omp'. 6694 6695 * OpenMP expansion 6696 6697 If OpenMP generation (`-fopenmp') is enabled, this pass expands 6698 parallel regions into their own functions to be invoked by the 6699 thread library. The pass is located in `omp-low.c' and is 6700 described by `pass_expand_omp'. 6701 6702 * Lower control flow 6703 6704 This pass flattens `if' statements (`COND_EXPR') and moves lexical 6705 bindings (`BIND_EXPR') out of line. After this pass, all `if' 6706 statements will have exactly two `goto' statements in its `then' 6707 and `else' arms. Lexical binding information for each statement 6708 will be found in `TREE_BLOCK' rather than being inferred from its 6709 position under a `BIND_EXPR'. This pass is found in 6710 `gimple-low.c' and is described by `pass_lower_cf'. 6711 6712 * Lower exception handling control flow 6713 6714 This pass decomposes high-level exception handling constructs 6715 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that 6716 explicitly represents the control flow involved. After this pass, 6717 `lookup_stmt_eh_region' will return a non-negative number for any 6718 statement that may have EH control flow semantics; examine 6719 `tree_can_throw_internal' or `tree_can_throw_external' for exact 6720 semantics. Exact control flow may be extracted from 6721 `foreach_reachable_handler'. The EH region nesting tree is defined 6722 in `except.h' and built in `except.c'. The lowering pass itself 6723 is in `tree-eh.c' and is described by `pass_lower_eh'. 6724 6725 * Build the control flow graph 6726 6727 This pass decomposes a function into basic blocks and creates all 6728 of the edges that connect them. It is located in `tree-cfg.c' and 6729 is described by `pass_build_cfg'. 6730 6731 * Find all referenced variables 6732 6733 This pass walks the entire function and collects an array of all 6734 variables referenced in the function, `referenced_vars'. The 6735 index at which a variable is found in the array is used as a UID 6736 for the variable within this function. This data is needed by the 6737 SSA rewriting routines. The pass is located in `tree-dfa.c' and 6738 is described by `pass_referenced_vars'. 6739 6740 * Enter static single assignment form 6741 6742 This pass rewrites the function such that it is in SSA form. After 6743 this pass, all `is_gimple_reg' variables will be referenced by 6744 `SSA_NAME', and all occurrences of other variables will be 6745 annotated with `VDEFS' and `VUSES'; PHI nodes will have been 6746 inserted as necessary for each basic block. This pass is located 6747 in `tree-ssa.c' and is described by `pass_build_ssa'. 6748 6749 * Warn for uninitialized variables 6750 6751 This pass scans the function for uses of `SSA_NAME's that are fed 6752 by default definition. For non-parameter variables, such uses are 6753 uninitialized. The pass is run twice, before and after 6754 optimization (if turned on). In the first pass we only warn for 6755 uses that are positively uninitialized; in the second pass we warn 6756 for uses that are possibly uninitialized. The pass is located in 6757 `tree-ssa.c' and is defined by `pass_early_warn_uninitialized' and 6758 `pass_late_warn_uninitialized'. 6759 6760 * Dead code elimination 6761 6762 This pass scans the function for statements without side effects 6763 whose result is unused. It does not do memory life analysis, so 6764 any value that is stored in memory is considered used. The pass 6765 is run multiple times throughout the optimization process. It is 6766 located in `tree-ssa-dce.c' and is described by `pass_dce'. 6767 6768 * Dominator optimizations 6769 6770 This pass performs trivial dominator-based copy and constant 6771 propagation, expression simplification, and jump threading. It is 6772 run multiple times throughout the optimization process. It is 6773 located in `tree-ssa-dom.c' and is described by `pass_dominator'. 6774 6775 * Forward propagation of single-use variables 6776 6777 This pass attempts to remove redundant computation by substituting 6778 variables that are used once into the expression that uses them and 6779 seeing if the result can be simplified. It is located in 6780 `tree-ssa-forwprop.c' and is described by `pass_forwprop'. 6781 6782 * Copy Renaming 6783 6784 This pass attempts to change the name of compiler temporaries 6785 involved in copy operations such that SSA->normal can coalesce the 6786 copy away. When compiler temporaries are copies of user 6787 variables, it also renames the compiler temporary to the user 6788 variable resulting in better use of user symbols. It is located 6789 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'. 6790 6791 * PHI node optimizations 6792 6793 This pass recognizes forms of PHI inputs that can be represented as 6794 conditional expressions and rewrites them into straight line code. 6795 It is located in `tree-ssa-phiopt.c' and is described by 6796 `pass_phiopt'. 6797 6798 * May-alias optimization 6799 6800 This pass performs a flow sensitive SSA-based points-to analysis. 6801 The resulting may-alias, must-alias, and escape analysis 6802 information is used to promote variables from in-memory 6803 addressable objects to non-aliased variables that can be renamed 6804 into SSA form. We also update the `VDEF'/`VUSE' memory tags for 6805 non-renameable aggregates so that we get fewer false kills. The 6806 pass is located in `tree-ssa-alias.c' and is described by 6807 `pass_may_alias'. 6808 6809 Interprocedural points-to information is located in 6810 `tree-ssa-structalias.c' and described by `pass_ipa_pta'. 6811 6812 * Profiling 6813 6814 This pass rewrites the function in order to collect runtime block 6815 and value profiling data. Such data may be fed back into the 6816 compiler on a subsequent run so as to allow optimization based on 6817 expected execution frequencies. The pass is located in 6818 `predict.c' and is described by `pass_profile'. 6819 6820 * Lower complex arithmetic 6821 6822 This pass rewrites complex arithmetic operations into their 6823 component scalar arithmetic operations. The pass is located in 6824 `tree-complex.c' and is described by `pass_lower_complex'. 6825 6826 * Scalar replacement of aggregates 6827 6828 This pass rewrites suitable non-aliased local aggregate variables 6829 into a set of scalar variables. The resulting scalar variables are 6830 rewritten into SSA form, which allows subsequent optimization 6831 passes to do a significantly better job with them. The pass is 6832 located in `tree-sra.c' and is described by `pass_sra'. 6833 6834 * Dead store elimination 6835 6836 This pass eliminates stores to memory that are subsequently 6837 overwritten by another store, without any intervening loads. The 6838 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'. 6839 6840 * Tail recursion elimination 6841 6842 This pass transforms tail recursion into a loop. It is located in 6843 `tree-tailcall.c' and is described by `pass_tail_recursion'. 6844 6845 * Forward store motion 6846 6847 This pass sinks stores and assignments down the flowgraph closer 6848 to their use point. The pass is located in `tree-ssa-sink.c' and 6849 is described by `pass_sink_code'. 6850 6851 * Partial redundancy elimination 6852 6853 This pass eliminates partially redundant computations, as well as 6854 performing load motion. The pass is located in `tree-ssa-pre.c' 6855 and is described by `pass_pre'. 6856 6857 Just before partial redundancy elimination, if 6858 `-funsafe-math-optimizations' is on, GCC tries to convert 6859 divisions to multiplications by the reciprocal. The pass is 6860 located in `tree-ssa-math-opts.c' and is described by 6861 `pass_cse_reciprocal'. 6862 6863 * Full redundancy elimination 6864 6865 This is a simpler form of PRE that only eliminates redundancies 6866 that occur on all paths. It is located in `tree-ssa-pre.c' and 6867 described by `pass_fre'. 6868 6869 * Loop optimization 6870 6871 The main driver of the pass is placed in `tree-ssa-loop.c' and 6872 described by `pass_loop'. 6873 6874 The optimizations performed by this pass are: 6875 6876 Loop invariant motion. This pass moves only invariants that would 6877 be hard to handle on RTL level (function calls, operations that 6878 expand to nontrivial sequences of insns). With `-funswitch-loops' 6879 it also moves operands of conditions that are invariant out of the 6880 loop, so that we can use just trivial invariantness analysis in 6881 loop unswitching. The pass also includes store motion. The pass 6882 is implemented in `tree-ssa-loop-im.c'. 6883 6884 Canonical induction variable creation. This pass creates a simple 6885 counter for number of iterations of the loop and replaces the exit 6886 condition of the loop using it, in case when a complicated 6887 analysis is necessary to determine the number of iterations. 6888 Later optimizations then may determine the number easily. The 6889 pass is implemented in `tree-ssa-loop-ivcanon.c'. 6890 6891 Induction variable optimizations. This pass performs standard 6892 induction variable optimizations, including strength reduction, 6893 induction variable merging and induction variable elimination. 6894 The pass is implemented in `tree-ssa-loop-ivopts.c'. 6895 6896 Loop unswitching. This pass moves the conditional jumps that are 6897 invariant out of the loops. To achieve this, a duplicate of the 6898 loop is created for each possible outcome of conditional jump(s). 6899 The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass 6900 should eventually replace the RTL level loop unswitching in 6901 `loop-unswitch.c', but currently the RTL level pass is not 6902 completely redundant yet due to deficiencies in tree level alias 6903 analysis. 6904 6905 The optimizations also use various utility functions contained in 6906 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and 6907 `cfgloopmanip.c'. 6908 6909 Vectorization. This pass transforms loops to operate on vector 6910 types instead of scalar types. Data parallelism across loop 6911 iterations is exploited to group data elements from consecutive 6912 iterations into a vector and operate on them in parallel. 6913 Depending on available target support the loop is conceptually 6914 unrolled by a factor `VF' (vectorization factor), which is the 6915 number of elements operated upon in parallel in each iteration, 6916 and the `VF' copies of each scalar operation are fused to form a 6917 vector operation. Additional loop transformations such as peeling 6918 and versioning may take place to align the number of iterations, 6919 and to align the memory accesses in the loop. The pass is 6920 implemented in `tree-vectorizer.c' (the main driver), 6921 `tree-vect-loop.c' and `tree-vect-loop-manip.c' (loop specific 6922 parts and general loop utilities), `tree-vect-slp' (loop-aware SLP 6923 functionality), `tree-vect-stmts.c' and `tree-vect-data-refs.c'. 6924 Analysis of data references is in `tree-data-ref.c'. 6925 6926 SLP Vectorization. This pass performs vectorization of 6927 straight-line code. The pass is implemented in `tree-vectorizer.c' 6928 (the main driver), `tree-vect-slp.c', `tree-vect-stmts.c' and 6929 `tree-vect-data-refs.c'. 6930 6931 Autoparallelization. This pass splits the loop iteration space to 6932 run into several threads. The pass is implemented in 6933 `tree-parloops.c'. 6934 6935 Graphite is a loop transformation framework based on the polyhedral 6936 model. Graphite stands for Gimple Represented as Polyhedra. The 6937 internals of this infrastructure are documented in 6938 `http://gcc.gnu.org/wiki/Graphite'. The passes working on this 6939 representation are implemented in the various `graphite-*' files. 6940 6941 * Tree level if-conversion for vectorizer 6942 6943 This pass applies if-conversion to simple loops to help vectorizer. 6944 We identify if convertible loops, if-convert statements and merge 6945 basic blocks in one big block. The idea is to present loop in such 6946 form so that vectorizer can have one to one mapping between 6947 statements and available vector operations. This pass is located 6948 in `tree-if-conv.c' and is described by `pass_if_conversion'. 6949 6950 * Conditional constant propagation 6951 6952 This pass relaxes a lattice of values in order to identify those 6953 that must be constant even in the presence of conditional branches. 6954 The pass is located in `tree-ssa-ccp.c' and is described by 6955 `pass_ccp'. 6956 6957 A related pass that works on memory loads and stores, and not just 6958 register values, is located in `tree-ssa-ccp.c' and described by 6959 `pass_store_ccp'. 6960 6961 * Conditional copy propagation 6962 6963 This is similar to constant propagation but the lattice of values 6964 is the "copy-of" relation. It eliminates redundant copies from the 6965 code. The pass is located in `tree-ssa-copy.c' and described by 6966 `pass_copy_prop'. 6967 6968 A related pass that works on memory copies, and not just register 6969 copies, is located in `tree-ssa-copy.c' and described by 6970 `pass_store_copy_prop'. 6971 6972 * Value range propagation 6973 6974 This transformation is similar to constant propagation but instead 6975 of propagating single constant values, it propagates known value 6976 ranges. The implementation is based on Patterson's range 6977 propagation algorithm (Accurate Static Branch Prediction by Value 6978 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 6979 Patterson's algorithm, this implementation does not propagate 6980 branch probabilities nor it uses more than a single range per SSA 6981 name. This means that the current implementation cannot be used 6982 for branch prediction (though adapting it would not be difficult). 6983 The pass is located in `tree-vrp.c' and is described by `pass_vrp'. 6984 6985 * Folding built-in functions 6986 6987 This pass simplifies built-in functions, as applicable, with 6988 constant arguments or with inferable string lengths. It is 6989 located in `tree-ssa-ccp.c' and is described by 6990 `pass_fold_builtins'. 6991 6992 * Split critical edges 6993 6994 This pass identifies critical edges and inserts empty basic blocks 6995 such that the edge is no longer critical. The pass is located in 6996 `tree-cfg.c' and is described by `pass_split_crit_edges'. 6997 6998 * Control dependence dead code elimination 6999 7000 This pass is a stronger form of dead code elimination that can 7001 eliminate unnecessary control flow statements. It is located in 7002 `tree-ssa-dce.c' and is described by `pass_cd_dce'. 7003 7004 * Tail call elimination 7005 7006 This pass identifies function calls that may be rewritten into 7007 jumps. No code transformation is actually applied here, but the 7008 data and control flow problem is solved. The code transformation 7009 requires target support, and so is delayed until RTL. In the 7010 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility. 7011 The pass is located in `tree-tailcall.c' and is described by 7012 `pass_tail_calls'. The RTL transformation is handled by 7013 `fixup_tail_calls' in `calls.c'. 7014 7015 * Warn for function return without value 7016 7017 For non-void functions, this pass locates return statements that do 7018 not specify a value and issues a warning. Such a statement may 7019 have been injected by falling off the end of the function. This 7020 pass is run last so that we have as much time as possible to prove 7021 that the statement is not reachable. It is located in 7022 `tree-cfg.c' and is described by `pass_warn_function_return'. 7023 7024 * Mudflap statement annotation 7025 7026 If mudflap is enabled, we rewrite some memory accesses with code to 7027 validate that the memory access is correct. In particular, 7028 expressions involving pointer dereferences (`INDIRECT_REF', 7029 `ARRAY_REF', etc.) are replaced by code that checks the selected 7030 address range against the mudflap runtime's database of valid 7031 regions. This check includes an inline lookup into a 7032 direct-mapped cache, based on shift/mask operations of the pointer 7033 value, with a fallback function call into the runtime. The pass 7034 is located in `tree-mudflap.c' and is described by 7035 `pass_mudflap_2'. 7036 7037 * Leave static single assignment form 7038 7039 This pass rewrites the function such that it is in normal form. At 7040 the same time, we eliminate as many single-use temporaries as 7041 possible, so the intermediate language is no longer GIMPLE, but 7042 GENERIC. The pass is located in `tree-outof-ssa.c' and is 7043 described by `pass_del_ssa'. 7044 7045 * Merge PHI nodes that feed into one another 7046 7047 This is part of the CFG cleanup passes. It attempts to join PHI 7048 nodes from a forwarder CFG block into another block with PHI 7049 nodes. The pass is located in `tree-cfgcleanup.c' and is 7050 described by `pass_merge_phi'. 7051 7052 * Return value optimization 7053 7054 If a function always returns the same local variable, and that 7055 local variable is an aggregate type, then the variable is replaced 7056 with the return value for the function (i.e., the function's 7057 DECL_RESULT). This is equivalent to the C++ named return value 7058 optimization applied to GIMPLE. The pass is located in 7059 `tree-nrv.c' and is described by `pass_nrv'. 7060 7061 * Return slot optimization 7062 7063 If a function returns a memory object and is called as `var = 7064 foo()', this pass tries to change the call so that the address of 7065 `var' is sent to the caller to avoid an extra memory copy. This 7066 pass is located in `tree-nrv.c' and is described by 7067 `pass_return_slot'. 7068 7069 * Optimize calls to `__builtin_object_size' 7070 7071 This is a propagation pass similar to CCP that tries to remove 7072 calls to `__builtin_object_size' when the size of the object can be 7073 computed at compile-time. This pass is located in 7074 `tree-object-size.c' and is described by `pass_object_sizes'. 7075 7076 * Loop invariant motion 7077 7078 This pass removes expensive loop-invariant computations out of 7079 loops. The pass is located in `tree-ssa-loop.c' and described by 7080 `pass_lim'. 7081 7082 * Loop nest optimizations 7083 7084 This is a family of loop transformations that works on loop nests. 7085 It includes loop interchange, scaling, skewing and reversal and 7086 they are all geared to the optimization of data locality in array 7087 traversals and the removal of dependencies that hamper 7088 optimizations such as loop parallelization and vectorization. The 7089 pass is located in `tree-loop-linear.c' and described by 7090 `pass_linear_transform'. 7091 7092 * Removal of empty loops 7093 7094 This pass removes loops with no code in them. The pass is located 7095 in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'. 7096 7097 * Unrolling of small loops 7098 7099 This pass completely unrolls loops with few iterations. The pass 7100 is located in `tree-ssa-loop-ivcanon.c' and described by 7101 `pass_complete_unroll'. 7102 7103 * Predictive commoning 7104 7105 This pass makes the code reuse the computations from the previous 7106 iterations of the loops, especially loads and stores to memory. 7107 It does so by storing the values of these computations to a bank 7108 of temporary variables that are rotated at the end of loop. To 7109 avoid the need for this rotation, the loop is then unrolled and 7110 the copies of the loop body are rewritten to use the appropriate 7111 version of the temporary variable. This pass is located in 7112 `tree-predcom.c' and described by `pass_predcom'. 7113 7114 * Array prefetching 7115 7116 This pass issues prefetch instructions for array references inside 7117 loops. The pass is located in `tree-ssa-loop-prefetch.c' and 7118 described by `pass_loop_prefetch'. 7119 7120 * Reassociation 7121 7122 This pass rewrites arithmetic expressions to enable optimizations 7123 that operate on them, like redundancy elimination and 7124 vectorization. The pass is located in `tree-ssa-reassoc.c' and 7125 described by `pass_reassoc'. 7126 7127 * Optimization of `stdarg' functions 7128 7129 This pass tries to avoid the saving of register arguments into the 7130 stack on entry to `stdarg' functions. If the function doesn't use 7131 any `va_start' macros, no registers need to be saved. If 7132 `va_start' macros are used, the `va_list' variables don't escape 7133 the function, it is only necessary to save registers that will be 7134 used in `va_arg' macros. For instance, if `va_arg' is only used 7135 with integral types in the function, floating point registers 7136 don't need to be saved. This pass is located in `tree-stdarg.c' 7137 and described by `pass_stdarg'. 7138 7139 7140 7141File: gccint.info, Node: RTL passes, Prev: Tree SSA passes, Up: Passes 7142 71439.5 RTL passes 7144============== 7145 7146The following briefly describes the RTL generation and optimization 7147passes that are run after the Tree optimization passes. 7148 7149 * RTL generation 7150 7151 The source files for RTL generation include `stmt.c', `calls.c', 7152 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and 7153 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the 7154 machine description by the program `genemit', is used in this 7155 pass. The header file `expr.h' is used for communication within 7156 this pass. 7157 7158 The header files `insn-flags.h' and `insn-codes.h', generated from 7159 the machine description by the programs `genflags' and `gencodes', 7160 tell this pass which standard names are available for use and 7161 which patterns correspond to them. 7162 7163 * Generation of exception landing pads 7164 7165 This pass generates the glue that handles communication between the 7166 exception handling library routines and the exception handlers 7167 within the function. Entry points in the function that are 7168 invoked by the exception handling library are called "landing 7169 pads". The code for this pass is located in `except.c'. 7170 7171 * Control flow graph cleanup 7172 7173 This pass removes unreachable code, simplifies jumps to next, 7174 jumps to jump, jumps across jumps, etc. The pass is run multiple 7175 times. For historical reasons, it is occasionally referred to as 7176 the "jump optimization pass". The bulk of the code for this pass 7177 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c' 7178 and `jump.c'. 7179 7180 * Forward propagation of single-def values 7181 7182 This pass attempts to remove redundant computation by substituting 7183 variables that come from a single definition, and seeing if the 7184 result can be simplified. It performs copy propagation and 7185 addressing mode selection. The pass is run twice, with values 7186 being propagated into loops only on the second run. The code is 7187 located in `fwprop.c'. 7188 7189 * Common subexpression elimination 7190 7191 This pass removes redundant computation within basic blocks, and 7192 optimizes addressing modes based on cost. The pass is run twice. 7193 The code for this pass is located in `cse.c'. 7194 7195 * Global common subexpression elimination 7196 7197 This pass performs two different types of GCSE depending on 7198 whether you are optimizing for size or not (LCM based GCSE tends 7199 to increase code size for a gain in speed, while Morel-Renvoise 7200 based GCSE does not). When optimizing for size, GCSE is done 7201 using Morel-Renvoise Partial Redundancy Elimination, with the 7202 exception that it does not try to move invariants out of 7203 loops--that is left to the loop optimization pass. If MR PRE 7204 GCSE is done, code hoisting (aka unification) is also done, as 7205 well as load motion. If you are optimizing for speed, LCM (lazy 7206 code motion) based GCSE is done. LCM is based on the work of 7207 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop 7208 invariant code motion. We also perform load and store motion when 7209 optimizing for speed. Regardless of which type of GCSE is used, 7210 the GCSE pass also performs global constant and copy propagation. 7211 The source file for this pass is `gcse.c', and the LCM routines 7212 are in `lcm.c'. 7213 7214 * Loop optimization 7215 7216 This pass performs several loop related optimizations. The source 7217 files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop 7218 analysis and manipulation code. Initialization and finalization 7219 of loop structures is handled by `loop-init.c'. A loop invariant 7220 motion pass is implemented in `loop-invariant.c'. Basic block 7221 level optimizations--unrolling, peeling and unswitching loops-- 7222 are implemented in `loop-unswitch.c' and `loop-unroll.c'. 7223 Replacing of the exit condition of loops by special 7224 machine-dependent instructions is handled by `loop-doloop.c'. 7225 7226 * Jump bypassing 7227 7228 This pass is an aggressive form of GCSE that transforms the control 7229 flow graph of a function by propagating constants into conditional 7230 branch instructions. The source file for this pass is `gcse.c'. 7231 7232 * If conversion 7233 7234 This pass attempts to replace conditional branches and surrounding 7235 assignments with arithmetic, boolean value producing comparison 7236 instructions, and conditional move instructions. In the very last 7237 invocation after reload/LRA, it will generate predicated 7238 instructions when supported by the target. The code is located in 7239 `ifcvt.c'. 7240 7241 * Web construction 7242 7243 This pass splits independent uses of each pseudo-register. This 7244 can improve effect of the other transformation, such as CSE or 7245 register allocation. The code for this pass is located in `web.c'. 7246 7247 * Instruction combination 7248 7249 This pass attempts to combine groups of two or three instructions 7250 that are related by data flow into single instructions. It 7251 combines the RTL expressions for the instructions by substitution, 7252 simplifies the result using algebra, and then attempts to match 7253 the result against the machine description. The code is located 7254 in `combine.c'. 7255 7256 * Register movement 7257 7258 This pass looks for cases where matching constraints would force an 7259 instruction to need a reload, and this reload would be a 7260 register-to-register move. It then attempts to change the 7261 registers used by the instruction to avoid the move instruction. 7262 The code is located in `regmove.c'. 7263 7264 * Mode switching optimization 7265 7266 This pass looks for instructions that require the processor to be 7267 in a specific "mode" and minimizes the number of mode changes 7268 required to satisfy all users. What these modes are, and what 7269 they apply to are completely target-specific. The code for this 7270 pass is located in `mode-switching.c'. 7271 7272 * Modulo scheduling 7273 7274 This pass looks at innermost loops and reorders their instructions 7275 by overlapping different iterations. Modulo scheduling is 7276 performed immediately before instruction scheduling. The code for 7277 this pass is located in `modulo-sched.c'. 7278 7279 * Instruction scheduling 7280 7281 This pass looks for instructions whose output will not be 7282 available by the time that it is used in subsequent instructions. 7283 Memory loads and floating point instructions often have this 7284 behavior on RISC machines. It re-orders instructions within a 7285 basic block to try to separate the definition and use of items 7286 that otherwise would cause pipeline stalls. This pass is 7287 performed twice, before and after register allocation. The code 7288 for this pass is located in `haifa-sched.c', `sched-deps.c', 7289 `sched-ebb.c', `sched-rgn.c' and `sched-vis.c'. 7290 7291 * Register allocation 7292 7293 These passes make sure that all occurrences of pseudo registers are 7294 eliminated, either by allocating them to a hard register, replacing 7295 them by an equivalent expression (e.g. a constant) or by placing 7296 them on the stack. This is done in several subpasses: 7297 7298 * Register move optimizations. This pass makes some simple RTL 7299 code transformations which improve the subsequent register 7300 allocation. The source file is `regmove.c'. 7301 7302 * The integrated register allocator (IRA). It is called 7303 integrated because coalescing, register live range splitting, 7304 and hard register preferencing are done on-the-fly during 7305 coloring. It also has better integration with the reload/LRA 7306 pass. Pseudo-registers spilled by the allocator or the 7307 reload/LRA have still a chance to get hard-registers if the 7308 reload/LRA evicts some pseudo-registers from hard-registers. 7309 The allocator helps to choose better pseudos for spilling 7310 based on their live ranges and to coalesce stack slots 7311 allocated for the spilled pseudo-registers. IRA is a regional 7312 register allocator which is transformed into Chaitin-Briggs 7313 allocator if there is one region. By default, IRA chooses 7314 regions using register pressure but the user can force it to 7315 use one region or regions corresponding to all loops. 7316 7317 Source files of the allocator are `ira.c', `ira-build.c', 7318 `ira-costs.c', `ira-conflicts.c', `ira-color.c', 7319 `ira-emit.c', `ira-lives', plus header files `ira.h' and 7320 `ira-int.h' used for the communication between the allocator 7321 and the rest of the compiler and between the IRA files. 7322 7323 * Reloading. This pass renumbers pseudo registers with the 7324 hardware registers numbers they were allocated. Pseudo 7325 registers that did not get hard registers are replaced with 7326 stack slots. Then it finds instructions that are invalid 7327 because a value has failed to end up in a register, or has 7328 ended up in a register of the wrong kind. It fixes up these 7329 instructions by reloading the problematical values 7330 temporarily into registers. Additional instructions are 7331 generated to do the copying. 7332 7333 The reload pass also optionally eliminates the frame pointer 7334 and inserts instructions to save and restore call-clobbered 7335 registers around calls. 7336 7337 Source files are `reload.c' and `reload1.c', plus the header 7338 `reload.h' used for communication between them. 7339 7340 * This pass is a modern replacement of the reload pass. Source 7341 files are `lra.c', `lra-assign.c', `lra-coalesce.c', 7342 `lra-constraints.c', `lra-eliminations.c', `lra-equivs.c', 7343 `lra-lives.c', `lra-saves.c', `lra-spills.c', the header 7344 `lra-int.h' used for communication between them, and the 7345 header `lra.h' used for communication between LRA and the 7346 rest of compiler. 7347 7348 Unlike the reload pass, intermediate LRA decisions are 7349 reflected in RTL as much as possible. This reduces the 7350 number of target-dependent macros and hooks, leaving 7351 instruction constraints as the primary source of control. 7352 7353 LRA is run on targets for which TARGET_LRA_P returns true. 7354 7355 * Basic block reordering 7356 7357 This pass implements profile guided code positioning. If profile 7358 information is not available, various types of static analysis are 7359 performed to make the predictions normally coming from the profile 7360 feedback (IE execution frequency, branch probability, etc). It is 7361 implemented in the file `bb-reorder.c', and the various prediction 7362 routines are in `predict.c'. 7363 7364 * Variable tracking 7365 7366 This pass computes where the variables are stored at each position 7367 in code and generates notes describing the variable locations to 7368 RTL code. The location lists are then generated according to these 7369 notes to debug information if the debugging information format 7370 supports location lists. The code is located in `var-tracking.c'. 7371 7372 * Delayed branch scheduling 7373 7374 This optional pass attempts to find instructions that can go into 7375 the delay slots of other instructions, usually jumps and calls. 7376 The code for this pass is located in `reorg.c'. 7377 7378 * Branch shortening 7379 7380 On many RISC machines, branch instructions have a limited range. 7381 Thus, longer sequences of instructions must be used for long 7382 branches. In this pass, the compiler figures out what how far 7383 each instruction will be from each other instruction, and 7384 therefore whether the usual instructions, or the longer sequences, 7385 must be used for each branch. The code for this pass is located 7386 in `final.c'. 7387 7388 * Register-to-stack conversion 7389 7390 Conversion from usage of some hard registers to usage of a register 7391 stack may be done at this point. Currently, this is supported only 7392 for the floating-point registers of the Intel 80387 coprocessor. 7393 The code for this pass is located in `reg-stack.c'. 7394 7395 * Final 7396 7397 This pass outputs the assembler code for the function. The source 7398 files are `final.c' plus `insn-output.c'; the latter is generated 7399 automatically from the machine description by the tool `genoutput'. 7400 The header file `conditions.h' is used for communication between 7401 these files. If mudflap is enabled, the queue of deferred 7402 declarations and any addressed constants (e.g., string literals) 7403 is processed by `mudflap_finish_file' into a synthetic constructor 7404 function containing calls into the mudflap runtime. 7405 7406 * Debugging information output 7407 7408 This is run after final because it must output the stack slot 7409 offsets for pseudo registers that did not get hard registers. 7410 Source files are `dbxout.c' for DBX symbol table format, 7411 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF 7412 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for 7413 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol 7414 table format. 7415 7416 7417 7418File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 7419 742010 RTL Representation 7421********************* 7422 7423The last part of the compiler work is done on a low-level intermediate 7424representation called Register Transfer Language. In this language, the 7425instructions to be output are described, pretty much one by one, in an 7426algebraic form that describes what the instruction does. 7427 7428 RTL is inspired by Lisp lists. It has both an internal form, made up 7429of structures that point at other structures, and a textual form that 7430is used in the machine description and in printed debugging dumps. The 7431textual form uses nested parentheses to indicate the pointers in the 7432internal form. 7433 7434* Menu: 7435 7436* RTL Objects:: Expressions vs vectors vs strings vs integers. 7437* RTL Classes:: Categories of RTL expression objects, and their structure. 7438* Accessors:: Macros to access expression operands or vector elts. 7439* Special Accessors:: Macros to access specific annotations on RTL. 7440* Flags:: Other flags in an RTL expression. 7441* Machine Modes:: Describing the size and format of a datum. 7442* Constants:: Expressions with constant values. 7443* Regs and Memory:: Expressions representing register contents or memory. 7444* Arithmetic:: Expressions representing arithmetic on other expressions. 7445* Comparisons:: Expressions representing comparison of expressions. 7446* Bit-Fields:: Expressions representing bit-fields in memory or reg. 7447* Vector Operations:: Expressions involving vector datatypes. 7448* Conversions:: Extending, truncating, floating or fixing. 7449* RTL Declarations:: Declaring volatility, constancy, etc. 7450* Side Effects:: Expressions for storing in registers, etc. 7451* Incdec:: Embedded side-effects for autoincrement addressing. 7452* Assembler:: Representing `asm' with operands. 7453* Debug Information:: Expressions representing debugging information. 7454* Insns:: Expression types for entire insns. 7455* Calls:: RTL representation of function call insns. 7456* Sharing:: Some expressions are unique; others *must* be copied. 7457* Reading RTL:: Reading textual RTL from a file. 7458 7459 7460File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 7461 746210.1 RTL Object Types 7463===================== 7464 7465RTL uses five kinds of objects: expressions, integers, wide integers, 7466strings and vectors. Expressions are the most important ones. An RTL 7467expression ("RTX", for short) is a C structure, but it is usually 7468referred to with a pointer; a type that is given the typedef name `rtx'. 7469 7470 An integer is simply an `int'; their written form uses decimal digits. 7471A wide integer is an integral object whose type is `HOST_WIDE_INT'; 7472their written form uses decimal digits. 7473 7474 A string is a sequence of characters. In core it is represented as a 7475`char *' in usual C fashion, and it is written in C syntax as well. 7476However, strings in RTL may never be null. If you write an empty 7477string in a machine description, it is represented in core as a null 7478pointer rather than as a pointer to a null character. In certain 7479contexts, these null pointers instead of strings are valid. Within RTL 7480code, strings are most commonly found inside `symbol_ref' expressions, 7481but they appear in other contexts in the RTL expressions that make up 7482machine descriptions. 7483 7484 In a machine description, strings are normally written with double 7485quotes, as you would in C. However, strings in machine descriptions may 7486extend over many lines, which is invalid C, and adjacent string 7487constants are not concatenated as they are in C. Any string constant 7488may be surrounded with a single set of parentheses. Sometimes this 7489makes the machine description easier to read. 7490 7491 There is also a special syntax for strings, which can be useful when C 7492code is embedded in a machine description. Wherever a string can 7493appear, it is also valid to write a C-style brace block. The entire 7494brace block, including the outermost pair of braces, is considered to be 7495the string constant. Double quote characters inside the braces are not 7496special. Therefore, if you write string constants in the C code, you 7497need not escape each quote character with a backslash. 7498 7499 A vector contains an arbitrary number of pointers to expressions. The 7500number of elements in the vector is explicitly present in the vector. 7501The written form of a vector consists of square brackets (`[...]') 7502surrounding the elements, in sequence and with whitespace separating 7503them. Vectors of length zero are not created; null pointers are used 7504instead. 7505 7506 Expressions are classified by "expression codes" (also called RTX 7507codes). The expression code is a name defined in `rtl.def', which is 7508also (in uppercase) a C enumeration constant. The possible expression 7509codes and their meanings are machine-independent. The code of an RTX 7510can be extracted with the macro `GET_CODE (X)' and altered with 7511`PUT_CODE (X, NEWCODE)'. 7512 7513 The expression code determines how many operands the expression 7514contains, and what kinds of objects they are. In RTL, unlike Lisp, you 7515cannot tell by looking at an operand what kind of object it is. 7516Instead, you must know from its context--from the expression code of 7517the containing expression. For example, in an expression of code 7518`subreg', the first operand is to be regarded as an expression and the 7519second operand as an integer. In an expression of code `plus', there 7520are two operands, both of which are to be regarded as expressions. In 7521a `symbol_ref' expression, there is one operand, which is to be 7522regarded as a string. 7523 7524 Expressions are written as parentheses containing the name of the 7525expression type, its flags and machine mode if any, and then the 7526operands of the expression (separated by spaces). 7527 7528 Expression code names in the `md' file are written in lowercase, but 7529when they appear in C code they are written in uppercase. In this 7530manual, they are shown as follows: `const_int'. 7531 7532 In a few contexts a null pointer is valid where an expression is 7533normally wanted. The written form of this is `(nil)'. 7534 7535 7536File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 7537 753810.2 RTL Classes and Formats 7539============================ 7540 7541The various expression codes are divided into several "classes", which 7542are represented by single characters. You can determine the class of 7543an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently, 7544`rtl.def' defines these classes: 7545 7546`RTX_OBJ' 7547 An RTX code that represents an actual object, such as a register 7548 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is 7549 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in 7550 this class, but in class `x'. 7551 7552`RTX_CONST_OBJ' 7553 An RTX code that represents a constant object. `HIGH' is also 7554 included in this class. 7555 7556`RTX_COMPARE' 7557 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'. 7558 7559`RTX_COMM_COMPARE' 7560 An RTX code for a symmetric (commutative) comparison, such as `EQ' 7561 or `ORDERED'. 7562 7563`RTX_UNARY' 7564 An RTX code for a unary arithmetic operation, such as `NEG', 7565 `NOT', or `ABS'. This category also includes value extension 7566 (sign or zero) and conversions between integer and floating point. 7567 7568`RTX_COMM_ARITH' 7569 An RTX code for a commutative binary operation, such as `PLUS' or 7570 `AND'. `NE' and `EQ' are comparisons, so they have class `<'. 7571 7572`RTX_BIN_ARITH' 7573 An RTX code for a non-commutative binary operation, such as 7574 `MINUS', `DIV', or `ASHIFTRT'. 7575 7576`RTX_BITFIELD_OPS' 7577 An RTX code for a bit-field operation. Currently only 7578 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and 7579 are lvalues (so they can be used for insertion as well). *Note 7580 Bit-Fields::. 7581 7582`RTX_TERNARY' 7583 An RTX code for other three input operations. Currently only 7584 `IF_THEN_ELSE', `VEC_MERGE', `SIGN_EXTRACT', `ZERO_EXTRACT', and 7585 `FMA'. 7586 7587`RTX_INSN' 7588 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and 7589 `CALL_INSN'. *Note Insns::. 7590 7591`RTX_MATCH' 7592 An RTX code for something that matches in insns, such as 7593 `MATCH_DUP'. These only occur in machine descriptions. 7594 7595`RTX_AUTOINC' 7596 An RTX code for an auto-increment addressing mode, such as 7597 `POST_INC'. 7598 7599`RTX_EXTRA' 7600 All other RTX codes. This category includes the remaining codes 7601 used only in machine descriptions (`DEFINE_*', etc.). It also 7602 includes all the codes describing side effects (`SET', `USE', 7603 `CLOBBER', etc.) and the non-insns that may appear on an insn 7604 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is 7605 also part of this class. 7606 7607 For each expression code, `rtl.def' specifies the number of contained 7608objects and their kinds using a sequence of characters called the 7609"format" of the expression code. For example, the format of `subreg' 7610is `ei'. 7611 7612 These are the most commonly used format characters: 7613 7614`e' 7615 An expression (actually a pointer to an expression). 7616 7617`i' 7618 An integer. 7619 7620`w' 7621 A wide integer. 7622 7623`s' 7624 A string. 7625 7626`E' 7627 A vector of expressions. 7628 7629 A few other format characters are used occasionally: 7630 7631`u' 7632 `u' is equivalent to `e' except that it is printed differently in 7633 debugging dumps. It is used for pointers to insns. 7634 7635`n' 7636 `n' is equivalent to `i' except that it is printed differently in 7637 debugging dumps. It is used for the line number or code number of 7638 a `note' insn. 7639 7640`S' 7641 `S' indicates a string which is optional. In the RTL objects in 7642 core, `S' is equivalent to `s', but when the object is read, from 7643 an `md' file, the string value of this operand may be omitted. An 7644 omitted string is taken to be the null string. 7645 7646`V' 7647 `V' indicates a vector which is optional. In the RTL objects in 7648 core, `V' is equivalent to `E', but when the object is read from 7649 an `md' file, the vector value of this operand may be omitted. An 7650 omitted vector is effectively the same as a vector of no elements. 7651 7652`B' 7653 `B' indicates a pointer to basic block structure. 7654 7655`0' 7656 `0' means a slot whose contents do not fit any normal category. 7657 `0' slots are not printed at all in dumps, and are often used in 7658 special ways by small parts of the compiler. 7659 7660 There are macros to get the number of operands and the format of an 7661expression code: 7662 7663`GET_RTX_LENGTH (CODE)' 7664 Number of operands of an RTX of code CODE. 7665 7666`GET_RTX_FORMAT (CODE)' 7667 The format of an RTX of code CODE, as a C string. 7668 7669 Some classes of RTX codes always have the same format. For example, it 7670is safe to assume that all comparison operations have format `ee'. 7671 7672`1' 7673 All codes of this class have format `e'. 7674 7675`<' 7676`c' 7677`2' 7678 All codes of these classes have format `ee'. 7679 7680`b' 7681`3' 7682 All codes of these classes have format `eee'. 7683 7684`i' 7685 All codes of this class have formats that begin with `iuueiee'. 7686 *Note Insns::. Note that not all RTL objects linked onto an insn 7687 chain are of class `i'. 7688 7689`o' 7690`m' 7691`x' 7692 You can make no assumptions about the format of these codes. 7693 7694 7695File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 7696 769710.3 Access to Operands 7698======================= 7699 7700Operands of expressions are accessed using the macros `XEXP', `XINT', 7701`XWINT' and `XSTR'. Each of these macros takes two arguments: an 7702expression-pointer (RTX) and an operand number (counting from zero). 7703Thus, 7704 7705 XEXP (X, 2) 7706 7707accesses operand 2 of expression X, as an expression. 7708 7709 XINT (X, 2) 7710 7711accesses the same operand as an integer. `XSTR', used in the same 7712fashion, would access it as a string. 7713 7714 Any operand can be accessed as an integer, as an expression or as a 7715string. You must choose the correct method of access for the kind of 7716value actually stored in the operand. You would do this based on the 7717expression code of the containing expression. That is also how you 7718would know how many operands there are. 7719 7720 For example, if X is a `subreg' expression, you know that it has two 7721operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, 77221)'. If you did `XINT (X, 0)', you would get the address of the 7723expression operand but cast as an integer; that might occasionally be 7724useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP 7725(X, 1)' would also compile without error, and would return the second, 7726integer operand cast as an expression pointer, which would probably 7727result in a crash when accessed. Nothing stops you from writing `XEXP 7728(X, 28)' either, but this will access memory past the end of the 7729expression with unpredictable results. 7730 7731 Access to operands which are vectors is more complicated. You can use 7732the macro `XVEC' to get the vector-pointer itself, or the macros 7733`XVECEXP' and `XVECLEN' to access the elements and length of a vector. 7734 7735`XVEC (EXP, IDX)' 7736 Access the vector-pointer which is operand number IDX in EXP. 7737 7738`XVECLEN (EXP, IDX)' 7739 Access the length (number of elements) in the vector which is in 7740 operand number IDX in EXP. This value is an `int'. 7741 7742`XVECEXP (EXP, IDX, ELTNUM)' 7743 Access element number ELTNUM in the vector which is in operand 7744 number IDX in EXP. This value is an RTX. 7745 7746 It is up to you to make sure that ELTNUM is not negative and is 7747 less than `XVECLEN (EXP, IDX)'. 7748 7749 All the macros defined in this section expand into lvalues and 7750therefore can be used to assign the operands, lengths and vector 7751elements as well as to access them. 7752 7753 7754File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 7755 775610.4 Access to Special Operands 7757=============================== 7758 7759Some RTL nodes have special annotations associated with them. 7760 7761`MEM' 7762 7763 `MEM_ALIAS_SET (X)' 7764 If 0, X is not in any alias set, and may alias anything. 7765 Otherwise, X can only alias `MEM's in a conflicting alias 7766 set. This value is set in a language-dependent manner in the 7767 front-end, and should not be altered in the back-end. In 7768 some front-ends, these numbers may correspond in some way to 7769 types, or other language-level entities, but they need not, 7770 and the back-end makes no such assumptions. These set 7771 numbers are tested with `alias_sets_conflict_p'. 7772 7773 `MEM_EXPR (X)' 7774 If this register is known to hold the value of some user-level 7775 declaration, this is that tree node. It may also be a 7776 `COMPONENT_REF', in which case this is some field reference, 7777 and `TREE_OPERAND (X, 0)' contains the declaration, or 7778 another `COMPONENT_REF', or null if there is no compile-time 7779 object associated with the reference. 7780 7781 `MEM_OFFSET_KNOWN_P (X)' 7782 True if the offset of the memory reference from `MEM_EXPR' is 7783 known. `MEM_OFFSET (X)' provides the offset if so. 7784 7785 `MEM_OFFSET (X)' 7786 The offset from the start of `MEM_EXPR'. The value is only 7787 valid if `MEM_OFFSET_KNOWN_P (X)' is true. 7788 7789 `MEM_SIZE_KNOWN_P (X)' 7790 True if the size of the memory reference is known. `MEM_SIZE 7791 (X)' provides its size if so. 7792 7793 `MEM_SIZE (X)' 7794 The size in bytes of the memory reference. This is mostly 7795 relevant for `BLKmode' references as otherwise the size is 7796 implied by the mode. The value is only valid if 7797 `MEM_SIZE_KNOWN_P (X)' is true. 7798 7799 `MEM_ALIGN (X)' 7800 The known alignment in bits of the memory reference. 7801 7802 `MEM_ADDR_SPACE (X)' 7803 The address space of the memory reference. This will 7804 commonly be zero for the generic address space. 7805 7806`REG' 7807 7808 `ORIGINAL_REGNO (X)' 7809 This field holds the number the register "originally" had; 7810 for a pseudo register turned into a hard reg this will hold 7811 the old pseudo register number. 7812 7813 `REG_EXPR (X)' 7814 If this register is known to hold the value of some user-level 7815 declaration, this is that tree node. 7816 7817 `REG_OFFSET (X)' 7818 If this register is known to hold the value of some user-level 7819 declaration, this is the offset into that logical storage. 7820 7821`SYMBOL_REF' 7822 7823 `SYMBOL_REF_DECL (X)' 7824 If the `symbol_ref' X was created for a `VAR_DECL' or a 7825 `FUNCTION_DECL', that tree is recorded here. If this value is 7826 null, then X was created by back end code generation routines, 7827 and there is no associated front end symbol table entry. 7828 7829 `SYMBOL_REF_DECL' may also point to a tree of class `'c'', 7830 that is, some sort of constant. In this case, the 7831 `symbol_ref' is an entry in the per-file constant pool; 7832 again, there is no associated front end symbol table entry. 7833 7834 `SYMBOL_REF_CONSTANT (X)' 7835 If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 7836 pool entry for X. It is null otherwise. 7837 7838 `SYMBOL_REF_DATA (X)' 7839 A field of opaque type used to store `SYMBOL_REF_DECL' or 7840 `SYMBOL_REF_CONSTANT'. 7841 7842 `SYMBOL_REF_FLAGS (X)' 7843 In a `symbol_ref', this is used to communicate various 7844 predicates about the symbol. Some of these are common enough 7845 to be computed by common code, some are specific to the 7846 target. The common bits are: 7847 7848 `SYMBOL_FLAG_FUNCTION' 7849 Set if the symbol refers to a function. 7850 7851 `SYMBOL_FLAG_LOCAL' 7852 Set if the symbol is local to this "module". See 7853 `TARGET_BINDS_LOCAL_P'. 7854 7855 `SYMBOL_FLAG_EXTERNAL' 7856 Set if this symbol is not defined in this translation 7857 unit. Note that this is not the inverse of 7858 `SYMBOL_FLAG_LOCAL'. 7859 7860 `SYMBOL_FLAG_SMALL' 7861 Set if the symbol is located in the small data section. 7862 See `TARGET_IN_SMALL_DATA_P'. 7863 7864 `SYMBOL_REF_TLS_MODEL (X)' 7865 This is a multi-bit field accessor that returns the 7866 `tls_model' to be used for a thread-local storage 7867 symbol. It returns zero for non-thread-local symbols. 7868 7869 `SYMBOL_FLAG_HAS_BLOCK_INFO' 7870 Set if the symbol has `SYMBOL_REF_BLOCK' and 7871 `SYMBOL_REF_BLOCK_OFFSET' fields. 7872 7873 `SYMBOL_FLAG_ANCHOR' 7874 Set if the symbol is used as a section anchor. "Section 7875 anchors" are symbols that have a known position within 7876 an `object_block' and that can be used to access nearby 7877 members of that block. They are used to implement 7878 `-fsection-anchors'. 7879 7880 If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO' 7881 will be too. 7882 7883 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for 7884 the target's use. 7885 7886`SYMBOL_REF_BLOCK (X)' 7887 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block' 7888 structure to which the symbol belongs, or `NULL' if it has not 7889 been assigned a block. 7890 7891`SYMBOL_REF_BLOCK_OFFSET (X)' 7892 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 7893 the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative 7894 if X has not yet been assigned to a block, or it has not been 7895 given an offset within that block. 7896 7897 7898File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 7899 790010.5 Flags in an RTL Expression 7901=============================== 7902 7903RTL expressions contain several flags (one-bit bit-fields) that are 7904used in certain types of expression. Most often they are accessed with 7905the following macros, which expand into lvalues. 7906 7907`CONSTANT_POOL_ADDRESS_P (X)' 7908 Nonzero in a `symbol_ref' if it refers to part of the current 7909 function's constant pool. For most targets these addresses are in 7910 a `.rodata' section entirely separate from the function, but for 7911 some targets the addresses are close to the beginning of the 7912 function. In either case GCC assumes these addresses can be 7913 addressed directly, perhaps with the help of base registers. 7914 Stored in the `unchanging' field and printed as `/u'. 7915 7916`RTL_CONST_CALL_P (X)' 7917 In a `call_insn' indicates that the insn represents a call to a 7918 const function. Stored in the `unchanging' field and printed as 7919 `/u'. 7920 7921`RTL_PURE_CALL_P (X)' 7922 In a `call_insn' indicates that the insn represents a call to a 7923 pure function. Stored in the `return_val' field and printed as 7924 `/i'. 7925 7926`RTL_CONST_OR_PURE_CALL_P (X)' 7927 In a `call_insn', true if `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' 7928 is true. 7929 7930`RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 7931 In a `call_insn' indicates that the insn represents a possibly 7932 infinite looping call to a const or pure function. Stored in the 7933 `call' field and printed as `/c'. Only true if one of 7934 `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' is true. 7935 7936`INSN_ANNULLED_BRANCH_P (X)' 7937 In a `jump_insn', `call_insn', or `insn' indicates that the branch 7938 is an annulling one. See the discussion under `sequence' below. 7939 Stored in the `unchanging' field and printed as `/u'. 7940 7941`INSN_DELETED_P (X)' 7942 In an `insn', `call_insn', `jump_insn', `code_label', `barrier', 7943 or `note', nonzero if the insn has been deleted. Stored in the 7944 `volatil' field and printed as `/v'. 7945 7946`INSN_FROM_TARGET_P (X)' 7947 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a 7948 branch, indicates that the insn is from the target of the branch. 7949 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn 7950 will only be executed if the branch is taken. For annulled 7951 branches with `INSN_FROM_TARGET_P' clear, the insn will be 7952 executed only if the branch is not taken. When 7953 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be 7954 executed. Stored in the `in_struct' field and printed as `/s'. 7955 7956`LABEL_PRESERVE_P (X)' 7957 In a `code_label' or `note', indicates that the label is 7958 referenced by code or data not visible to the RTL of a given 7959 function. Labels referenced by a non-local goto will have this 7960 bit set. Stored in the `in_struct' field and printed as `/s'. 7961 7962`LABEL_REF_NONLOCAL_P (X)' 7963 In `label_ref' and `reg_label' expressions, nonzero if this is a 7964 reference to a non-local label. Stored in the `volatil' field and 7965 printed as `/v'. 7966 7967`MEM_KEEP_ALIAS_SET_P (X)' 7968 In `mem' expressions, 1 if we should keep the alias set for this 7969 mem unchanged when we access a component. Set to 1, for example, 7970 when we are already in a non-addressable component of an aggregate. 7971 Stored in the `jump' field and printed as `/j'. 7972 7973`MEM_VOLATILE_P (X)' 7974 In `mem', `asm_operands', and `asm_input' expressions, nonzero for 7975 volatile memory references. Stored in the `volatil' field and 7976 printed as `/v'. 7977 7978`MEM_NOTRAP_P (X)' 7979 In `mem', nonzero for memory references that will not trap. 7980 Stored in the `call' field and printed as `/c'. 7981 7982`MEM_POINTER (X)' 7983 Nonzero in a `mem' if the memory reference holds a pointer. 7984 Stored in the `frame_related' field and printed as `/f'. 7985 7986`REG_FUNCTION_VALUE_P (X)' 7987 Nonzero in a `reg' if it is the place in which this function's 7988 value is going to be returned. (This happens only in a hard 7989 register.) Stored in the `return_val' field and printed as `/i'. 7990 7991`REG_POINTER (X)' 7992 Nonzero in a `reg' if the register holds a pointer. Stored in the 7993 `frame_related' field and printed as `/f'. 7994 7995`REG_USERVAR_P (X)' 7996 In a `reg', nonzero if it corresponds to a variable present in the 7997 user's source code. Zero for temporaries generated internally by 7998 the compiler. Stored in the `volatil' field and printed as `/v'. 7999 8000 The same hard register may be used also for collecting the values 8001 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero 8002 in this kind of use. 8003 8004`RTX_FRAME_RELATED_P (X)' 8005 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or 8006 `set' which is part of a function prologue and sets the stack 8007 pointer, sets the frame pointer, or saves a register. This flag 8008 should also be set on an instruction that sets up a temporary 8009 register to use in place of the frame pointer. Stored in the 8010 `frame_related' field and printed as `/f'. 8011 8012 In particular, on RISC targets where there are limits on the sizes 8013 of immediate constants, it is sometimes impossible to reach the 8014 register save area directly from the stack pointer. In that case, 8015 a temporary register is used that is near enough to the register 8016 save area, and the Canonical Frame Address, i.e., DWARF2's logical 8017 frame pointer, register must (temporarily) be changed to be this 8018 temporary register. So, the instruction that sets this temporary 8019 register must be marked as `RTX_FRAME_RELATED_P'. 8020 8021 If the marked instruction is overly complex (defined in terms of 8022 what `dwarf2out_frame_debug_expr' can handle), you will also have 8023 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the 8024 instruction. This note should contain a simple expression of the 8025 computation performed by this instruction, i.e., one that 8026 `dwarf2out_frame_debug_expr' can handle. 8027 8028 This flag is required for exception handling support on targets 8029 with RTL prologues. 8030 8031`MEM_READONLY_P (X)' 8032 Nonzero in a `mem', if the memory is statically allocated and 8033 read-only. 8034 8035 Read-only in this context means never modified during the lifetime 8036 of the program, not necessarily in ROM or in write-disabled pages. 8037 A common example of the later is a shared library's global offset 8038 table. This table is initialized by the runtime loader, so the 8039 memory is technically writable, but after control is transferred 8040 from the runtime loader to the application, this memory will never 8041 be subsequently modified. 8042 8043 Stored in the `unchanging' field and printed as `/u'. 8044 8045`SCHED_GROUP_P (X)' 8046 During instruction scheduling, in an `insn', `call_insn' or 8047 `jump_insn', indicates that the previous insn must be scheduled 8048 together with this insn. This is used to ensure that certain 8049 groups of instructions will not be split up by the instruction 8050 scheduling pass, for example, `use' insns before a `call_insn' may 8051 not be separated from the `call_insn'. Stored in the `in_struct' 8052 field and printed as `/s'. 8053 8054`SET_IS_RETURN_P (X)' 8055 For a `set', nonzero if it is for a return. Stored in the `jump' 8056 field and printed as `/j'. 8057 8058`SIBLING_CALL_P (X)' 8059 For a `call_insn', nonzero if the insn is a sibling call. Stored 8060 in the `jump' field and printed as `/j'. 8061 8062`STRING_POOL_ADDRESS_P (X)' 8063 For a `symbol_ref' expression, nonzero if it addresses this 8064 function's string constant pool. Stored in the `frame_related' 8065 field and printed as `/f'. 8066 8067`SUBREG_PROMOTED_UNSIGNED_P (X)' 8068 Returns a value greater then zero for a `subreg' that has 8069 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 8070 kept zero-extended, zero if it is kept sign-extended, and less 8071 then zero if it is extended some other way via the `ptr_extend' 8072 instruction. Stored in the `unchanging' field and `volatil' 8073 field, printed as `/u' and `/v'. This macro may only be used to 8074 get the value it may not be used to change the value. Use 8075 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 8076 8077`SUBREG_PROMOTED_UNSIGNED_SET (X)' 8078 Set the `unchanging' and `volatil' fields in a `subreg' to reflect 8079 zero, sign, or other extension. If `volatil' is zero, then 8080 `unchanging' as nonzero means zero extension and as zero means 8081 sign extension. If `volatil' is nonzero then some other type of 8082 extension was done via the `ptr_extend' instruction. 8083 8084`SUBREG_PROMOTED_VAR_P (X)' 8085 Nonzero in a `subreg' if it was made when accessing an object that 8086 was promoted to a wider mode in accord with the `PROMOTED_MODE' 8087 machine description macro (*note Storage Layout::). In this case, 8088 the mode of the `subreg' is the declared mode of the object and 8089 the mode of `SUBREG_REG' is the mode of the register that holds 8090 the object. Promoted variables are always either sign- or 8091 zero-extended to the wider mode on every assignment. Stored in 8092 the `in_struct' field and printed as `/s'. 8093 8094`SYMBOL_REF_USED (X)' 8095 In a `symbol_ref', indicates that X has been used. This is 8096 normally only used to ensure that X is only declared external 8097 once. Stored in the `used' field. 8098 8099`SYMBOL_REF_WEAK (X)' 8100 In a `symbol_ref', indicates that X has been declared weak. 8101 Stored in the `return_val' field and printed as `/i'. 8102 8103`SYMBOL_REF_FLAG (X)' 8104 In a `symbol_ref', this is used as a flag for machine-specific 8105 purposes. Stored in the `volatil' field and printed as `/v'. 8106 8107 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by 8108 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is 8109 mandatory if the target requires more than one bit of storage. 8110 8111`PREFETCH_SCHEDULE_BARRIER_P (X)' 8112 In a `prefetch', indicates that the prefetch is a scheduling 8113 barrier. No other INSNs will be moved over it. Stored in the 8114 `volatil' field and printed as `/v'. 8115 8116 These are the fields to which the above macros refer: 8117 8118`call' 8119 In a `mem', 1 means that the memory reference will not trap. 8120 8121 In a `call', 1 means that this pure or const call may possibly 8122 infinite loop. 8123 8124 In an RTL dump, this flag is represented as `/c'. 8125 8126`frame_related' 8127 In an `insn' or `set' expression, 1 means that it is part of a 8128 function prologue and sets the stack pointer, sets the frame 8129 pointer, saves a register, or sets up a temporary register to use 8130 in place of the frame pointer. 8131 8132 In `reg' expressions, 1 means that the register holds a pointer. 8133 8134 In `mem' expressions, 1 means that the memory reference holds a 8135 pointer. 8136 8137 In `symbol_ref' expressions, 1 means that the reference addresses 8138 this function's string constant pool. 8139 8140 In an RTL dump, this flag is represented as `/f'. 8141 8142`in_struct' 8143 In `reg' expressions, it is 1 if the register has its entire life 8144 contained within the test expression of some loop. 8145 8146 In `subreg' expressions, 1 means that the `subreg' is accessing an 8147 object that has had its mode promoted from a wider mode. 8148 8149 In `label_ref' expressions, 1 means that the referenced label is 8150 outside the innermost loop containing the insn in which the 8151 `label_ref' was found. 8152 8153 In `code_label' expressions, it is 1 if the label may never be 8154 deleted. This is used for labels which are the target of 8155 non-local gotos. Such a label that would have been deleted is 8156 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'. 8157 8158 In an `insn' during dead-code elimination, 1 means that the insn is 8159 dead code. 8160 8161 In an `insn' or `jump_insn' during reorg for an insn in the delay 8162 slot of a branch, 1 means that this insn is from the target of the 8163 branch. 8164 8165 In an `insn' during instruction scheduling, 1 means that this insn 8166 must be scheduled as part of a group together with the previous 8167 insn. 8168 8169 In an RTL dump, this flag is represented as `/s'. 8170 8171`return_val' 8172 In `reg' expressions, 1 means the register contains the value to 8173 be returned by the current function. On machines that pass 8174 parameters in registers, the same register number may be used for 8175 parameters as well, but this flag is not set on such uses. 8176 8177 In `symbol_ref' expressions, 1 means the referenced symbol is weak. 8178 8179 In `call' expressions, 1 means the call is pure. 8180 8181 In an RTL dump, this flag is represented as `/i'. 8182 8183`jump' 8184 In a `mem' expression, 1 means we should keep the alias set for 8185 this mem unchanged when we access a component. 8186 8187 In a `set', 1 means it is for a return. 8188 8189 In a `call_insn', 1 means it is a sibling call. 8190 8191 In an RTL dump, this flag is represented as `/j'. 8192 8193`unchanging' 8194 In `reg' and `mem' expressions, 1 means that the value of the 8195 expression never changes. 8196 8197 In `subreg' expressions, it is 1 if the `subreg' references an 8198 unsigned object whose mode has been promoted to a wider mode. 8199 8200 In an `insn' or `jump_insn' in the delay slot of a branch 8201 instruction, 1 means an annulling branch should be used. 8202 8203 In a `symbol_ref' expression, 1 means that this symbol addresses 8204 something in the per-function constant pool. 8205 8206 In a `call_insn' 1 means that this instruction is a call to a const 8207 function. 8208 8209 In an RTL dump, this flag is represented as `/u'. 8210 8211`used' 8212 This flag is used directly (without an access macro) at the end of 8213 RTL generation for a function, to count the number of times an 8214 expression appears in insns. Expressions that appear more than 8215 once are copied, according to the rules for shared structure 8216 (*note Sharing::). 8217 8218 For a `reg', it is used directly (without an access macro) by the 8219 leaf register renumbering code to ensure that each register is only 8220 renumbered once. 8221 8222 In a `symbol_ref', it indicates that an external declaration for 8223 the symbol has already been written. 8224 8225`volatil' 8226 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if 8227 the memory reference is volatile. Volatile memory references may 8228 not be deleted, reordered or combined. 8229 8230 In a `symbol_ref' expression, it is used for machine-specific 8231 purposes. 8232 8233 In a `reg' expression, it is 1 if the value is a user-level 8234 variable. 0 indicates an internal compiler temporary. 8235 8236 In an `insn', 1 means the insn has been deleted. 8237 8238 In `label_ref' and `reg_label' expressions, 1 means a reference to 8239 a non-local label. 8240 8241 In `prefetch' expressions, 1 means that the containing insn is a 8242 scheduling barrier. 8243 8244 In an RTL dump, this flag is represented as `/v'. 8245 8246 8247File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 8248 824910.6 Machine Modes 8250================== 8251 8252A machine mode describes a size of data object and the representation 8253used for it. In the C code, machine modes are represented by an 8254enumeration type, `enum machine_mode', defined in `machmode.def'. Each 8255RTL expression has room for a machine mode and so do certain kinds of 8256tree expressions (declarations and types, to be precise). 8257 8258 In debugging dumps and machine descriptions, the machine mode of an RTL 8259expression is written after the expression code with a colon to separate 8260them. The letters `mode' which appear at the end of each machine mode 8261name are omitted. For example, `(reg:SI 38)' is a `reg' expression 8262with machine mode `SImode'. If the mode is `VOIDmode', it is not 8263written at all. 8264 8265 Here is a table of machine modes. The term "byte" below refers to an 8266object of `BITS_PER_UNIT' bits (*note Storage Layout::). 8267 8268`BImode' 8269 "Bit" mode represents a single bit, for predicate registers. 8270 8271`QImode' 8272 "Quarter-Integer" mode represents a single byte treated as an 8273 integer. 8274 8275`HImode' 8276 "Half-Integer" mode represents a two-byte integer. 8277 8278`PSImode' 8279 "Partial Single Integer" mode represents an integer which occupies 8280 four bytes but which doesn't really use all four. On some 8281 machines, this is the right mode to use for pointers. 8282 8283`SImode' 8284 "Single Integer" mode represents a four-byte integer. 8285 8286`PDImode' 8287 "Partial Double Integer" mode represents an integer which occupies 8288 eight bytes but which doesn't really use all eight. On some 8289 machines, this is the right mode to use for certain pointers. 8290 8291`DImode' 8292 "Double Integer" mode represents an eight-byte integer. 8293 8294`TImode' 8295 "Tetra Integer" (?) mode represents a sixteen-byte integer. 8296 8297`OImode' 8298 "Octa Integer" (?) mode represents a thirty-two-byte integer. 8299 8300`QFmode' 8301 "Quarter-Floating" mode represents a quarter-precision (single 8302 byte) floating point number. 8303 8304`HFmode' 8305 "Half-Floating" mode represents a half-precision (two byte) 8306 floating point number. 8307 8308`TQFmode' 8309 "Three-Quarter-Floating" (?) mode represents a 8310 three-quarter-precision (three byte) floating point number. 8311 8312`SFmode' 8313 "Single Floating" mode represents a four byte floating point 8314 number. In the common case, of a processor with IEEE arithmetic 8315 and 8-bit bytes, this is a single-precision IEEE floating point 8316 number; it can also be used for double-precision (on processors 8317 with 16-bit bytes) and single-precision VAX and IBM types. 8318 8319`DFmode' 8320 "Double Floating" mode represents an eight byte floating point 8321 number. In the common case, of a processor with IEEE arithmetic 8322 and 8-bit bytes, this is a double-precision IEEE floating point 8323 number. 8324 8325`XFmode' 8326 "Extended Floating" mode represents an IEEE extended floating point 8327 number. This mode only has 80 meaningful bits (ten bytes). Some 8328 processors require such numbers to be padded to twelve bytes, 8329 others to sixteen; this mode is used for either. 8330 8331`SDmode' 8332 "Single Decimal Floating" mode represents a four byte decimal 8333 floating point number (as distinct from conventional binary 8334 floating point). 8335 8336`DDmode' 8337 "Double Decimal Floating" mode represents an eight byte decimal 8338 floating point number. 8339 8340`TDmode' 8341 "Tetra Decimal Floating" mode represents a sixteen byte decimal 8342 floating point number all 128 of whose bits are meaningful. 8343 8344`TFmode' 8345 "Tetra Floating" mode represents a sixteen byte floating point 8346 number all 128 of whose bits are meaningful. One common use is the 8347 IEEE quad-precision format. 8348 8349`QQmode' 8350 "Quarter-Fractional" mode represents a single byte treated as a 8351 signed fractional number. The default format is "s.7". 8352 8353`HQmode' 8354 "Half-Fractional" mode represents a two-byte signed fractional 8355 number. The default format is "s.15". 8356 8357`SQmode' 8358 "Single Fractional" mode represents a four-byte signed fractional 8359 number. The default format is "s.31". 8360 8361`DQmode' 8362 "Double Fractional" mode represents an eight-byte signed 8363 fractional number. The default format is "s.63". 8364 8365`TQmode' 8366 "Tetra Fractional" mode represents a sixteen-byte signed 8367 fractional number. The default format is "s.127". 8368 8369`UQQmode' 8370 "Unsigned Quarter-Fractional" mode represents a single byte 8371 treated as an unsigned fractional number. The default format is 8372 ".8". 8373 8374`UHQmode' 8375 "Unsigned Half-Fractional" mode represents a two-byte unsigned 8376 fractional number. The default format is ".16". 8377 8378`USQmode' 8379 "Unsigned Single Fractional" mode represents a four-byte unsigned 8380 fractional number. The default format is ".32". 8381 8382`UDQmode' 8383 "Unsigned Double Fractional" mode represents an eight-byte unsigned 8384 fractional number. The default format is ".64". 8385 8386`UTQmode' 8387 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 8388 fractional number. The default format is ".128". 8389 8390`HAmode' 8391 "Half-Accumulator" mode represents a two-byte signed accumulator. 8392 The default format is "s8.7". 8393 8394`SAmode' 8395 "Single Accumulator" mode represents a four-byte signed 8396 accumulator. The default format is "s16.15". 8397 8398`DAmode' 8399 "Double Accumulator" mode represents an eight-byte signed 8400 accumulator. The default format is "s32.31". 8401 8402`TAmode' 8403 "Tetra Accumulator" mode represents a sixteen-byte signed 8404 accumulator. The default format is "s64.63". 8405 8406`UHAmode' 8407 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 8408 accumulator. The default format is "8.8". 8409 8410`USAmode' 8411 "Unsigned Single Accumulator" mode represents a four-byte unsigned 8412 accumulator. The default format is "16.16". 8413 8414`UDAmode' 8415 "Unsigned Double Accumulator" mode represents an eight-byte 8416 unsigned accumulator. The default format is "32.32". 8417 8418`UTAmode' 8419 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 8420 unsigned accumulator. The default format is "64.64". 8421 8422`CCmode' 8423 "Condition Code" mode represents the value of a condition code, 8424 which is a machine-specific set of bits used to represent the 8425 result of a comparison operation. Other machine-specific modes 8426 may also be used for the condition code. These modes are not used 8427 on machines that use `cc0' (*note Condition Code::). 8428 8429`BLKmode' 8430 "Block" mode represents values that are aggregates to which none of 8431 the other modes apply. In RTL, only memory references can have 8432 this mode, and only if they appear in string-move or vector 8433 instructions. On machines which have no such instructions, 8434 `BLKmode' will not appear in RTL. 8435 8436`VOIDmode' 8437 Void mode means the absence of a mode or an unspecified mode. For 8438 example, RTL expressions of code `const_int' have mode `VOIDmode' 8439 because they can be taken to have whatever mode the context 8440 requires. In debugging dumps of RTL, `VOIDmode' is expressed by 8441 the absence of any mode. 8442 8443`QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 8444 These modes stand for a complex number represented as a pair of 8445 floating point values. The floating point values are in `QFmode', 8446 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively. 8447 8448`CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 8449 These modes stand for a complex number represented as a pair of 8450 integer values. The integer values are in `QImode', `HImode', 8451 `SImode', `DImode', `TImode', and `OImode', respectively. 8452 8453 The machine description defines `Pmode' as a C macro which expands 8454into the machine mode used for addresses. Normally this is the mode 8455whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 8456 8457 The only modes which a machine description must support are `QImode', 8458and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and 8459`DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for 84608-byte structures and unions, but this can be prevented by overriding 8461the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have 8462the compiler use `TImode' for 16-byte structures and unions. Likewise, 8463you can arrange for the C type `short int' to avoid using `HImode'. 8464 8465 Very few explicit references to machine modes remain in the compiler 8466and these few references will soon be removed. Instead, the machine 8467modes are divided into mode classes. These are represented by the 8468enumeration type `enum mode_class' defined in `machmode.h'. The 8469possible mode classes are: 8470 8471`MODE_INT' 8472 Integer modes. By default these are `BImode', `QImode', `HImode', 8473 `SImode', `DImode', `TImode', and `OImode'. 8474 8475`MODE_PARTIAL_INT' 8476 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and 8477 `PDImode'. 8478 8479`MODE_FLOAT' 8480 Floating point modes. By default these are `QFmode', `HFmode', 8481 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'. 8482 8483`MODE_DECIMAL_FLOAT' 8484 Decimal floating point modes. By default these are `SDmode', 8485 `DDmode' and `TDmode'. 8486 8487`MODE_FRACT' 8488 Signed fractional modes. By default these are `QQmode', `HQmode', 8489 `SQmode', `DQmode' and `TQmode'. 8490 8491`MODE_UFRACT' 8492 Unsigned fractional modes. By default these are `UQQmode', 8493 `UHQmode', `USQmode', `UDQmode' and `UTQmode'. 8494 8495`MODE_ACCUM' 8496 Signed accumulator modes. By default these are `HAmode', 8497 `SAmode', `DAmode' and `TAmode'. 8498 8499`MODE_UACCUM' 8500 Unsigned accumulator modes. By default these are `UHAmode', 8501 `USAmode', `UDAmode' and `UTAmode'. 8502 8503`MODE_COMPLEX_INT' 8504 Complex integer modes. (These are not currently implemented). 8505 8506`MODE_COMPLEX_FLOAT' 8507 Complex floating point modes. By default these are `QCmode', 8508 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'. 8509 8510`MODE_FUNCTION' 8511 Algol or Pascal function variables including a static chain. 8512 (These are not currently implemented). 8513 8514`MODE_CC' 8515 Modes representing condition code values. These are `CCmode' plus 8516 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump 8517 Patterns::, also see *note Condition Code::. 8518 8519`MODE_RANDOM' 8520 This is a catchall mode class for modes which don't fit into the 8521 above classes. Currently `VOIDmode' and `BLKmode' are in 8522 `MODE_RANDOM'. 8523 8524 Here are some C macros that relate to machine modes: 8525 8526`GET_MODE (X)' 8527 Returns the machine mode of the RTX X. 8528 8529`PUT_MODE (X, NEWMODE)' 8530 Alters the machine mode of the RTX X to be NEWMODE. 8531 8532`NUM_MACHINE_MODES' 8533 Stands for the number of machine modes available on the target 8534 machine. This is one greater than the largest numeric value of any 8535 machine mode. 8536 8537`GET_MODE_NAME (M)' 8538 Returns the name of mode M as a string. 8539 8540`GET_MODE_CLASS (M)' 8541 Returns the mode class of mode M. 8542 8543`GET_MODE_WIDER_MODE (M)' 8544 Returns the next wider natural mode. For example, the expression 8545 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 8546 8547`GET_MODE_SIZE (M)' 8548 Returns the size in bytes of a datum of mode M. 8549 8550`GET_MODE_BITSIZE (M)' 8551 Returns the size in bits of a datum of mode M. 8552 8553`GET_MODE_IBIT (M)' 8554 Returns the number of integral bits of a datum of fixed-point mode 8555 M. 8556 8557`GET_MODE_FBIT (M)' 8558 Returns the number of fractional bits of a datum of fixed-point 8559 mode M. 8560 8561`GET_MODE_MASK (M)' 8562 Returns a bitmask containing 1 for all bits in a word that fit 8563 within mode M. This macro can only be used for modes whose 8564 bitsize is less than or equal to `HOST_BITS_PER_INT'. 8565 8566`GET_MODE_ALIGNMENT (M)' 8567 Return the required alignment, in bits, for an object of mode M. 8568 8569`GET_MODE_UNIT_SIZE (M)' 8570 Returns the size in bytes of the subunits of a datum of mode M. 8571 This is the same as `GET_MODE_SIZE' except in the case of complex 8572 modes. For them, the unit size is the size of the real or 8573 imaginary part. 8574 8575`GET_MODE_NUNITS (M)' 8576 Returns the number of units contained in a mode, i.e., 8577 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 8578 8579`GET_CLASS_NARROWEST_MODE (C)' 8580 Returns the narrowest mode in mode class C. 8581 8582 The global variables `byte_mode' and `word_mode' contain modes whose 8583classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 8584`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 8585and `SImode', respectively. 8586 8587 8588File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 8589 859010.7 Constant Expression Types 8591============================== 8592 8593The simplest RTL expressions are those that represent constant values. 8594 8595`(const_int I)' 8596 This type of expression represents the integer value I. I is 8597 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 8598 which is equivalent to `XWINT (EXP, 0)'. 8599 8600 Constants generated for modes with fewer bits than in 8601 `HOST_WIDE_INT' must be sign extended to full width (e.g., with 8602 `gen_int_mode'). For constants for modes with more bits than in 8603 `HOST_WIDE_INT' the implied high order bits of that constant are 8604 copies of the top bit. Note however that values are neither 8605 inherently signed nor inherently unsigned; where necessary, 8606 signedness is determined by the rtl operation instead. 8607 8608 There is only one expression object for the integer value zero; it 8609 is the value of the variable `const0_rtx'. Likewise, the only 8610 expression for integer value one is found in `const1_rtx', the only 8611 expression for integer value two is found in `const2_rtx', and the 8612 only expression for integer value negative one is found in 8613 `constm1_rtx'. Any attempt to create an expression of code 8614 `const_int' and value zero, one, two or negative one will return 8615 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 8616 appropriate. 8617 8618 Similarly, there is only one object for the integer whose value is 8619 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 8620 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 8621 point to the same object. If `STORE_FLAG_VALUE' is -1, 8622 `const_true_rtx' and `constm1_rtx' will point to the same object. 8623 8624`(const_double:M I0 I1 ...)' 8625 Represents either a floating-point constant of mode M or an 8626 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 8627 bits but small enough to fit within twice that number of bits (GCC 8628 does not provide a mechanism to represent even larger constants). 8629 In the latter case, M will be `VOIDmode'. For integral values 8630 constants for modes with more bits than twice the number in 8631 `HOST_WIDE_INT' the implied high order bits of that constant are 8632 copies of the top bit of `CONST_DOUBLE_HIGH'. Note however that 8633 integral values are neither inherently signed nor inherently 8634 unsigned; where necessary, signedness is determined by the rtl 8635 operation instead. 8636 8637 If M is `VOIDmode', the bits of the value are stored in I0 and I1. 8638 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 8639 I1 with `CONST_DOUBLE_HIGH'. 8640 8641 If the constant is floating point (regardless of its precision), 8642 then the number of integers used to store the value depends on the 8643 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers 8644 represent a floating point number, but not precisely in the target 8645 machine's or host machine's floating point format. To convert 8646 them to the precise bit pattern used by the target machine, use 8647 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 8648 Output::). 8649 8650`(const_fixed:M ...)' 8651 Represents a fixed-point constant of mode M. The operand is a 8652 data structure of type `struct fixed_value' and is accessed with 8653 the macro `CONST_FIXED_VALUE'. The high part of data is accessed 8654 with `CONST_FIXED_VALUE_HIGH'; the low part is accessed with 8655 `CONST_FIXED_VALUE_LOW'. 8656 8657`(const_vector:M [X0 X1 ...])' 8658 Represents a vector constant. The square brackets stand for the 8659 vector containing the constant elements. X0, X1 and so on are the 8660 `const_int', `const_double' or `const_fixed' elements. 8661 8662 The number of units in a `const_vector' is obtained with the macro 8663 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'. 8664 8665 Individual elements in a vector constant are accessed with the 8666 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V 8667 is the vector constant and N is the element desired. 8668 8669`(const_string STR)' 8670 Represents a constant string with value STR. Currently this is 8671 used only for insn attributes (*note Insn Attributes::) since 8672 constant strings in C are placed in memory. 8673 8674`(symbol_ref:MODE SYMBOL)' 8675 Represents the value of an assembler label for data. SYMBOL is a 8676 string that describes the name of the assembler label. If it 8677 starts with a `*', the label is the rest of SYMBOL not including 8678 the `*'. Otherwise, the label is SYMBOL, usually prefixed with 8679 `_'. 8680 8681 The `symbol_ref' contains a mode, which is usually `Pmode'. 8682 Usually that is the only mode for which a symbol is directly valid. 8683 8684`(label_ref:MODE LABEL)' 8685 Represents the value of an assembler label for code. It contains 8686 one operand, an expression, which must be a `code_label' or a 8687 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the 8688 instruction sequence to identify the place where the label should 8689 go. 8690 8691 The reason for using a distinct expression type for code label 8692 references is so that jump optimization can distinguish them. 8693 8694 The `label_ref' contains a mode, which is usually `Pmode'. 8695 Usually that is the only mode for which a label is directly valid. 8696 8697`(const:M EXP)' 8698 Represents a constant that is the result of an assembly-time 8699 arithmetic computation. The operand, EXP, is an expression that 8700 contains only constants (`const_int', `symbol_ref' and `label_ref' 8701 expressions) combined with `plus' and `minus'. However, not all 8702 combinations are valid, since the assembler cannot do arbitrary 8703 arithmetic on relocatable symbols. 8704 8705 M should be `Pmode'. 8706 8707`(high:M EXP)' 8708 Represents the high-order bits of EXP, usually a `symbol_ref'. 8709 The number of bits is machine-dependent and is normally the number 8710 of bits specified in an instruction that initializes the high 8711 order bits of a register. It is used with `lo_sum' to represent 8712 the typical two-instruction sequence used in RISC machines to 8713 reference a global memory location. 8714 8715 M should be `Pmode'. 8716 8717 The macro `CONST0_RTX (MODE)' refers to an expression with value 0 in 8718mode MODE. If mode MODE is of mode class `MODE_INT', it returns 8719`const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', it returns a 8720`CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 8721`CONST_VECTOR' expression in mode MODE. Similarly, the macro 8722`CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 8723and similarly for `CONST2_RTX'. The `CONST1_RTX' and `CONST2_RTX' 8724macros are undefined for vector modes. 8725 8726 8727File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 8728 872910.8 Registers and Memory 8730========================= 8731 8732Here are the RTL expression types for describing access to machine 8733registers and to main memory. 8734 8735`(reg:M N)' 8736 For small values of the integer N (those that are less than 8737 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 8738 register number N: a "hard register". For larger values of N, it 8739 stands for a temporary value or "pseudo register". The compiler's 8740 strategy is to generate code assuming an unlimited number of such 8741 pseudo registers, and later convert them into hard registers or 8742 into memory references. 8743 8744 M is the machine mode of the reference. It is necessary because 8745 machines can generally refer to each register in more than one 8746 mode. For example, a register may contain a full word but there 8747 may be instructions to refer to it as a half word or as a single 8748 byte, as well as instructions to refer to it as a floating point 8749 number of various precisions. 8750 8751 Even for a register that the machine can access in only one mode, 8752 the mode must always be specified. 8753 8754 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 8755 description, since the number of hard registers on the machine is 8756 an invariant characteristic of the machine. Note, however, that 8757 not all of the machine registers must be general registers. All 8758 the machine registers that can be used for storage of data are 8759 given hard register numbers, even those that can be used only in 8760 certain instructions or can hold only certain types of data. 8761 8762 A hard register may be accessed in various modes throughout one 8763 function, but each pseudo register is given a natural mode and is 8764 accessed only in that mode. When it is necessary to describe an 8765 access to a pseudo register using a nonnatural mode, a `subreg' 8766 expression is used. 8767 8768 A `reg' expression with a machine mode that specifies more than 8769 one word of data may actually stand for several consecutive 8770 registers. If in addition the register number specifies a 8771 hardware register, then it actually represents several consecutive 8772 hardware registers starting with the specified one. 8773 8774 Each pseudo register number used in a function's RTL code is 8775 represented by a unique `reg' expression. 8776 8777 Some pseudo register numbers, those within the range of 8778 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 8779 during the RTL generation phase and are eliminated before the 8780 optimization phases. These represent locations in the stack frame 8781 that cannot be determined until RTL generation for the function 8782 has been completed. The following virtual register numbers are 8783 defined: 8784 8785 `VIRTUAL_INCOMING_ARGS_REGNUM' 8786 This points to the first word of the incoming arguments 8787 passed on the stack. Normally these arguments are placed 8788 there by the caller, but the callee may have pushed some 8789 arguments that were previously passed in registers. 8790 8791 When RTL generation is complete, this virtual register is 8792 replaced by the sum of the register given by 8793 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 8794 8795 `VIRTUAL_STACK_VARS_REGNUM' 8796 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 8797 points to immediately above the first variable on the stack. 8798 Otherwise, it points to the first variable on the stack. 8799 8800 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 8801 register given by `FRAME_POINTER_REGNUM' and the value 8802 `STARTING_FRAME_OFFSET'. 8803 8804 `VIRTUAL_STACK_DYNAMIC_REGNUM' 8805 This points to the location of dynamically allocated memory 8806 on the stack immediately after the stack pointer has been 8807 adjusted by the amount of memory desired. 8808 8809 This virtual register is replaced by the sum of the register 8810 given by `STACK_POINTER_REGNUM' and the value 8811 `STACK_DYNAMIC_OFFSET'. 8812 8813 `VIRTUAL_OUTGOING_ARGS_REGNUM' 8814 This points to the location in the stack at which outgoing 8815 arguments should be written when the stack is pre-pushed 8816 (arguments pushed using push insns should always use 8817 `STACK_POINTER_REGNUM'). 8818 8819 This virtual register is replaced by the sum of the register 8820 given by `STACK_POINTER_REGNUM' and the value 8821 `STACK_POINTER_OFFSET'. 8822 8823`(subreg:M1 REG:M2 BYTENUM)' 8824 `subreg' expressions are used to refer to a register in a machine 8825 mode other than its natural one, or to refer to one register of a 8826 multi-part `reg' that actually refers to several registers. 8827 8828 Each pseudo register has a natural mode. If it is necessary to 8829 operate on it in a different mode, the register must be enclosed 8830 in a `subreg'. 8831 8832 There are currently three supported types for the first operand of 8833 a `subreg': 8834 * pseudo registers This is the most common case. Most 8835 `subreg's have pseudo `reg's as their first operand. 8836 8837 * mem `subreg's of `mem' were common in earlier versions of GCC 8838 and are still supported. During the reload pass these are 8839 replaced by plain `mem's. On machines that do not do 8840 instruction scheduling, use of `subreg's of `mem' are still 8841 used, but this is no longer recommended. Such `subreg's are 8842 considered to be `register_operand's rather than 8843 `memory_operand's before and during reload. Because of this, 8844 the scheduling passes cannot properly schedule instructions 8845 with `subreg's of `mem', so for machines that do scheduling, 8846 `subreg's of `mem' should never be used. To support this, 8847 the combine and recog passes have explicit code to inhibit 8848 the creation of `subreg's of `mem' when `INSN_SCHEDULING' is 8849 defined. 8850 8851 The use of `subreg's of `mem' after the reload pass is an area 8852 that is not well understood and should be avoided. There is 8853 still some code in the compiler to support this, but this 8854 code has possibly rotted. This use of `subreg's is 8855 discouraged and will most likely not be supported in the 8856 future. 8857 8858 * hard registers It is seldom necessary to wrap hard registers 8859 in `subreg's; such registers would normally reduce to a 8860 single `reg' rtx. This use of `subreg's is discouraged and 8861 may not be supported in the future. 8862 8863 8864 `subreg's of `subreg's are not supported. Using 8865 `simplify_gen_subreg' is the recommended way to avoid this problem. 8866 8867 `subreg's come in two distinct flavors, each having its own usage 8868 and rules: 8869 8870 Paradoxical subregs 8871 When M1 is strictly wider than M2, the `subreg' expression is 8872 called "paradoxical". The canonical test for this class of 8873 `subreg' is: 8874 8875 GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2) 8876 8877 Paradoxical `subreg's can be used as both lvalues and rvalues. 8878 When used as an lvalue, the low-order bits of the source value 8879 are stored in REG and the high-order bits are discarded. 8880 When used as an rvalue, the low-order bits of the `subreg' are 8881 taken from REG while the high-order bits may or may not be 8882 defined. 8883 8884 The high-order bits of rvalues are in the following 8885 circumstances: 8886 8887 * `subreg's of `mem' When M2 is smaller than a word, the 8888 macro `LOAD_EXTEND_OP', can control how the high-order 8889 bits are defined. 8890 8891 * `subreg' of `reg's The upper bits are defined when 8892 `SUBREG_PROMOTED_VAR_P' is true. 8893 `SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 8894 bits hold. Such subregs usually represent local 8895 variables, register variables and parameter pseudo 8896 variables that have been promoted to a wider mode. 8897 8898 8899 BYTENUM is always zero for a paradoxical `subreg', even on 8900 big-endian targets. 8901 8902 For example, the paradoxical `subreg': 8903 8904 (set (subreg:SI (reg:HI X) 0) Y) 8905 8906 stores the lower 2 bytes of Y in X and discards the upper 2 8907 bytes. A subsequent: 8908 8909 (set Z (subreg:SI (reg:HI X) 0)) 8910 8911 would set the lower two bytes of Z to Y and set the upper two 8912 bytes to an unknown value assuming `SUBREG_PROMOTED_VAR_P' is 8913 false. 8914 8915 Normal subregs 8916 When M1 is at least as narrow as M2 the `subreg' expression 8917 is called "normal". 8918 8919 Normal `subreg's restrict consideration to certain bits of 8920 REG. There are two cases. If M1 is smaller than a word, the 8921 `subreg' refers to the least-significant part (or "lowpart") 8922 of one word of REG. If M1 is word-sized or greater, the 8923 `subreg' refers to one or more complete words. 8924 8925 When used as an lvalue, `subreg' is a word-based accessor. 8926 Storing to a `subreg' modifies all the words of REG that 8927 overlap the `subreg', but it leaves the other words of REG 8928 alone. 8929 8930 When storing to a normal `subreg' that is smaller than a word, 8931 the other bits of the referenced word are usually left in an 8932 undefined state. This laxity makes it easier to generate 8933 efficient code for such instructions. To represent an 8934 instruction that preserves all the bits outside of those in 8935 the `subreg', use `strict_low_part' or `zero_extract' around 8936 the `subreg'. 8937 8938 BYTENUM must identify the offset of the first byte of the 8939 `subreg' from the start of REG, assuming that REG is laid out 8940 in memory order. The memory order of bytes is defined by two 8941 target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN': 8942 8943 * `WORDS_BIG_ENDIAN', if set to 1, says that byte number 8944 zero is part of the most significant word; otherwise, it 8945 is part of the least significant word. 8946 8947 * `BYTES_BIG_ENDIAN', if set to 1, says that byte number 8948 zero is the most significant byte within a word; 8949 otherwise, it is the least significant byte within a 8950 word. 8951 8952 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with 8953 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 8954 floating point values as if they had the same endianness as 8955 integer values. This works because they handle them solely 8956 as a collection of integer values, with no particular 8957 numerical value. Only real.c and the runtime libraries care 8958 about `FLOAT_WORDS_BIG_ENDIAN'. 8959 8960 Thus, 8961 8962 (subreg:HI (reg:SI X) 2) 8963 8964 on a `BYTES_BIG_ENDIAN', `UNITS_PER_WORD == 4' target is the 8965 same as 8966 8967 (subreg:HI (reg:SI X) 0) 8968 8969 on a little-endian, `UNITS_PER_WORD == 4' target. Both 8970 `subreg's access the lower two bytes of register X. 8971 8972 8973 A `MODE_PARTIAL_INT' mode behaves as if it were as wide as the 8974 corresponding `MODE_INT' mode, except that it has an unknown 8975 number of undefined bits. For example: 8976 8977 (subreg:PSI (reg:SI 0) 0) 8978 8979 accesses the whole of `(reg:SI 0)', but the exact relationship 8980 between the `PSImode' value and the `SImode' value is not defined. 8981 If we assume `UNITS_PER_WORD <= 4', then the following two 8982 `subreg's: 8983 8984 (subreg:PSI (reg:DI 0) 0) 8985 (subreg:PSI (reg:DI 0) 4) 8986 8987 represent independent 4-byte accesses to the two halves of 8988 `(reg:DI 0)'. Both `subreg's have an unknown number of undefined 8989 bits. 8990 8991 If `UNITS_PER_WORD <= 2' then these two `subreg's: 8992 8993 (subreg:HI (reg:PSI 0) 0) 8994 (subreg:HI (reg:PSI 0) 2) 8995 8996 represent independent 2-byte accesses that together span the whole 8997 of `(reg:PSI 0)'. Storing to the first `subreg' does not affect 8998 the value of the second, and vice versa. `(reg:PSI 0)' has an 8999 unknown number of undefined bits, so the assignment: 9000 9001 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 9002 9003 does not guarantee that `(subreg:HI (reg:PSI 0) 0)' has the value 9004 `(reg:HI 4)'. 9005 9006 The rules above apply to both pseudo REGs and hard REGs. If the 9007 semantics are not correct for particular combinations of M1, M2 9008 and hard REG, the target-specific code must ensure that those 9009 combinations are never used. For example: 9010 9011 CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS) 9012 9013 must be true for every class CLASS that includes REG. 9014 9015 The first operand of a `subreg' expression is customarily accessed 9016 with the `SUBREG_REG' macro and the second operand is customarily 9017 accessed with the `SUBREG_BYTE' macro. 9018 9019 It has been several years since a platform in which 9020 `BYTES_BIG_ENDIAN' not equal to `WORDS_BIG_ENDIAN' has been 9021 tested. Anyone wishing to support such a platform in the future 9022 may be confronted with code rot. 9023 9024`(scratch:M)' 9025 This represents a scratch register that will be required for the 9026 execution of a single instruction and not used subsequently. It is 9027 converted into a `reg' by either the local register allocator or 9028 the reload pass. 9029 9030 `scratch' is usually present inside a `clobber' operation (*note 9031 Side Effects::). 9032 9033`(cc0)' 9034 This refers to the machine's condition code register. It has no 9035 operands and may not have a machine mode. There are two ways to 9036 use it: 9037 9038 * To stand for a complete set of condition code flags. This is 9039 best on most machines, where each comparison sets the entire 9040 series of flags. 9041 9042 With this technique, `(cc0)' may be validly used in only two 9043 contexts: as the destination of an assignment (in test and 9044 compare instructions) and in comparison operators comparing 9045 against zero (`const_int' with value zero; that is to say, 9046 `const0_rtx'). 9047 9048 * To stand for a single flag that is the result of a single 9049 condition. This is useful on machines that have only a 9050 single flag bit, and in which comparison instructions must 9051 specify the condition to test. 9052 9053 With this technique, `(cc0)' may be validly used in only two 9054 contexts: as the destination of an assignment (in test and 9055 compare instructions) where the source is a comparison 9056 operator, and as the first operand of `if_then_else' (in a 9057 conditional branch). 9058 9059 There is only one expression object of code `cc0'; it is the value 9060 of the variable `cc0_rtx'. Any attempt to create an expression of 9061 code `cc0' will return `cc0_rtx'. 9062 9063 Instructions can set the condition code implicitly. On many 9064 machines, nearly all instructions set the condition code based on 9065 the value that they compute or store. It is not necessary to 9066 record these actions explicitly in the RTL because the machine 9067 description includes a prescription for recognizing the 9068 instructions that do so (by means of the macro 9069 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 9070 whose sole purpose is to set the condition code, and instructions 9071 that use the condition code, need mention `(cc0)'. 9072 9073 On some machines, the condition code register is given a register 9074 number and a `reg' is used instead of `(cc0)'. This is usually the 9075 preferable approach if only a small subset of instructions modify 9076 the condition code. Other machines store condition codes in 9077 general registers; in such cases a pseudo register should be used. 9078 9079 Some machines, such as the SPARC and RS/6000, have two sets of 9080 arithmetic instructions, one that sets and one that does not set 9081 the condition code. This is best handled by normally generating 9082 the instruction that does not set the condition code, and making a 9083 pattern that both performs the arithmetic and sets the condition 9084 code register (which would not be `(cc0)' in this case). For 9085 examples, search for `addcc' and `andcc' in `sparc.md'. 9086 9087`(pc)' 9088 This represents the machine's program counter. It has no operands 9089 and may not have a machine mode. `(pc)' may be validly used only 9090 in certain specific contexts in jump instructions. 9091 9092 There is only one expression object of code `pc'; it is the value 9093 of the variable `pc_rtx'. Any attempt to create an expression of 9094 code `pc' will return `pc_rtx'. 9095 9096 All instructions that do not jump alter the program counter 9097 implicitly by incrementing it, but there is no need to mention 9098 this in the RTL. 9099 9100`(mem:M ADDR ALIAS)' 9101 This RTX represents a reference to main memory at an address 9102 represented by the expression ADDR. M specifies how large a unit 9103 of memory is accessed. ALIAS specifies an alias set for the 9104 reference. In general two items are in different alias sets if 9105 they cannot reference the same memory address. 9106 9107 The construct `(mem:BLK (scratch))' is considered to alias all 9108 other memories. Thus it may be used as a memory barrier in 9109 epilogue stack deallocation patterns. 9110 9111`(concatM RTX RTX)' 9112 This RTX represents the concatenation of two other RTXs. This is 9113 used for complex values. It should only appear in the RTL 9114 attached to declarations and during RTL generation. It should not 9115 appear in the ordinary insn chain. 9116 9117`(concatnM [RTX ...])' 9118 This RTX represents the concatenation of all the RTX to make a 9119 single value. Like `concat', this should only appear in 9120 declarations, and not in the insn chain. 9121 9122 9123File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 9124 912510.9 RTL Expressions for Arithmetic 9126=================================== 9127 9128Unless otherwise specified, all the operands of arithmetic expressions 9129must be valid for mode M. An operand is valid for mode M if it has 9130mode M, or if it is a `const_int' or `const_double' and M is a mode of 9131class `MODE_INT'. 9132 9133 For commutative binary operations, constants should be placed in the 9134second operand. 9135 9136`(plus:M X Y)' 9137`(ss_plus:M X Y)' 9138`(us_plus:M X Y)' 9139 These three expressions all represent the sum of the values 9140 represented by X and Y carried out in machine mode M. They differ 9141 in their behavior on overflow of integer modes. `plus' wraps 9142 round modulo the width of M; `ss_plus' saturates at the maximum 9143 signed value representable in M; `us_plus' saturates at the 9144 maximum unsigned value. 9145 9146`(lo_sum:M X Y)' 9147 This expression represents the sum of X and the low-order bits of 9148 Y. It is used with `high' (*note Constants::) to represent the 9149 typical two-instruction sequence used in RISC machines to 9150 reference a global memory location. 9151 9152 The number of low order bits is machine-dependent but is normally 9153 the number of bits in a `Pmode' item minus the number of bits set 9154 by `high'. 9155 9156 M should be `Pmode'. 9157 9158`(minus:M X Y)' 9159`(ss_minus:M X Y)' 9160`(us_minus:M X Y)' 9161 These three expressions represent the result of subtracting Y from 9162 X, carried out in mode M. Behavior on overflow is the same as for 9163 the three variants of `plus' (see above). 9164 9165`(compare:M X Y)' 9166 Represents the result of subtracting Y from X for purposes of 9167 comparison. The result is computed without overflow, as if with 9168 infinite precision. 9169 9170 Of course, machines can't really subtract with infinite precision. 9171 However, they can pretend to do so when only the sign of the 9172 result will be used, which is the case when the result is stored 9173 in the condition code. And that is the _only_ way this kind of 9174 expression may validly be used: as a value to be stored in the 9175 condition codes, either `(cc0)' or a register. *Note 9176 Comparisons::. 9177 9178 The mode M is not related to the modes of X and Y, but instead is 9179 the mode of the condition code value. If `(cc0)' is used, it is 9180 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 9181 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or 9182 `CCmode', the operation returns sufficient information (in an 9183 unspecified format) so that any comparison operator can be applied 9184 to the result of the `COMPARE' operation. For other modes in 9185 class `MODE_CC', the operation only returns a subset of this 9186 information. 9187 9188 Normally, X and Y must have the same mode. Otherwise, `compare' 9189 is valid only if the mode of X is in class `MODE_INT' and Y is a 9190 `const_int' or `const_double' with mode `VOIDmode'. The mode of X 9191 determines what mode the comparison is to be done in; thus it must 9192 not be `VOIDmode'. 9193 9194 If one of the operands is a constant, it should be placed in the 9195 second operand and the comparison code adjusted as appropriate. 9196 9197 A `compare' specifying two `VOIDmode' constants is not valid since 9198 there is no way to know in what mode the comparison is to be 9199 performed; the comparison must either be folded during the 9200 compilation or the first operand must be loaded into a register 9201 while its mode is still known. 9202 9203`(neg:M X)' 9204`(ss_neg:M X)' 9205`(us_neg:M X)' 9206 These two expressions represent the negation (subtraction from 9207 zero) of the value represented by X, carried out in mode M. They 9208 differ in the behavior on overflow of integer modes. In the case 9209 of `neg', the negation of the operand may be a number not 9210 representable in mode M, in which case it is truncated to M. 9211 `ss_neg' and `us_neg' ensure that an out-of-bounds result 9212 saturates to the maximum or minimum signed or unsigned value. 9213 9214`(mult:M X Y)' 9215`(ss_mult:M X Y)' 9216`(us_mult:M X Y)' 9217 Represents the signed product of the values represented by X and Y 9218 carried out in machine mode M. `ss_mult' and `us_mult' ensure 9219 that an out-of-bounds result saturates to the maximum or minimum 9220 signed or unsigned value. 9221 9222 Some machines support a multiplication that generates a product 9223 wider than the operands. Write the pattern for this as 9224 9225 (mult:M (sign_extend:M X) (sign_extend:M Y)) 9226 9227 where M is wider than the modes of X and Y, which need not be the 9228 same. 9229 9230 For unsigned widening multiplication, use the same idiom, but with 9231 `zero_extend' instead of `sign_extend'. 9232 9233`(fma:M X Y Z)' 9234 Represents the `fma', `fmaf', and `fmal' builtin functions that do 9235 a combined multiply of X and Y and then adding toZ without doing 9236 an intermediate rounding step. 9237 9238`(div:M X Y)' 9239`(ss_div:M X Y)' 9240 Represents the quotient in signed division of X by Y, carried out 9241 in machine mode M. If M is a floating point mode, it represents 9242 the exact quotient; otherwise, the integerized quotient. `ss_div' 9243 ensures that an out-of-bounds result saturates to the maximum or 9244 minimum signed value. 9245 9246 Some machines have division instructions in which the operands and 9247 quotient widths are not all the same; you should represent such 9248 instructions using `truncate' and `sign_extend' as in, 9249 9250 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 9251 9252`(udiv:M X Y)' 9253`(us_div:M X Y)' 9254 Like `div' but represents unsigned division. `us_div' ensures 9255 that an out-of-bounds result saturates to the maximum or minimum 9256 unsigned value. 9257 9258`(mod:M X Y)' 9259`(umod:M X Y)' 9260 Like `div' and `udiv' but represent the remainder instead of the 9261 quotient. 9262 9263`(smin:M X Y)' 9264`(smax:M X Y)' 9265 Represents the smaller (for `smin') or larger (for `smax') of X 9266 and Y, interpreted as signed values in mode M. When used with 9267 floating point, if both operands are zeros, or if either operand 9268 is `NaN', then it is unspecified which of the two operands is 9269 returned as the result. 9270 9271`(umin:M X Y)' 9272`(umax:M X Y)' 9273 Like `smin' and `smax', but the values are interpreted as unsigned 9274 integers. 9275 9276`(not:M X)' 9277 Represents the bitwise complement of the value represented by X, 9278 carried out in mode M, which must be a fixed-point machine mode. 9279 9280`(and:M X Y)' 9281 Represents the bitwise logical-and of the values represented by X 9282 and Y, carried out in machine mode M, which must be a fixed-point 9283 machine mode. 9284 9285`(ior:M X Y)' 9286 Represents the bitwise inclusive-or of the values represented by X 9287 and Y, carried out in machine mode M, which must be a fixed-point 9288 mode. 9289 9290`(xor:M X Y)' 9291 Represents the bitwise exclusive-or of the values represented by X 9292 and Y, carried out in machine mode M, which must be a fixed-point 9293 mode. 9294 9295`(ashift:M X C)' 9296`(ss_ashift:M X C)' 9297`(us_ashift:M X C)' 9298 These three expressions represent the result of arithmetically 9299 shifting X left by C places. They differ in their behavior on 9300 overflow of integer modes. An `ashift' operation is a plain shift 9301 with no special behavior in case of a change in the sign bit; 9302 `ss_ashift' and `us_ashift' saturates to the minimum or maximum 9303 representable value if any of the bits shifted out differs from 9304 the final sign bit. 9305 9306 X have mode M, a fixed-point machine mode. C be a fixed-point 9307 mode or be a constant with mode `VOIDmode'; which mode is 9308 determined by the mode called for in the machine description entry 9309 for the left-shift instruction. For example, on the VAX, the mode 9310 of C is `QImode' regardless of M. 9311 9312`(lshiftrt:M X C)' 9313`(ashiftrt:M X C)' 9314 Like `ashift' but for right shift. Unlike the case for left shift, 9315 these two operations are distinct. 9316 9317`(rotate:M X C)' 9318`(rotatert:M X C)' 9319 Similar but represent left and right rotate. If C is a constant, 9320 use `rotate'. 9321 9322`(abs:M X)' 9323 9324`(ss_abs:M X)' 9325 Represents the absolute value of X, computed in mode M. `ss_abs' 9326 ensures that an out-of-bounds result saturates to the maximum 9327 signed value. 9328 9329`(sqrt:M X)' 9330 Represents the square root of X, computed in mode M. Most often M 9331 will be a floating point mode. 9332 9333`(ffs:M X)' 9334 Represents one plus the index of the least significant 1-bit in X, 9335 represented as an integer of mode M. (The value is zero if X is 9336 zero.) The mode of X must be M or `VOIDmode'. 9337 9338`(clrsb:M X)' 9339 Represents the number of redundant leading sign bits in X, 9340 represented as an integer of mode M, starting at the most 9341 significant bit position. This is one less than the number of 9342 leading sign bits (either 0 or 1), with no special cases. The 9343 mode of X must be M or `VOIDmode'. 9344 9345`(clz:M X)' 9346 Represents the number of leading 0-bits in X, represented as an 9347 integer of mode M, starting at the most significant bit position. 9348 If X is zero, the value is determined by 9349 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 9350 of the few expressions that is not invariant under widening. The 9351 mode of X must be M or `VOIDmode'. 9352 9353`(ctz:M X)' 9354 Represents the number of trailing 0-bits in X, represented as an 9355 integer of mode M, starting at the least significant bit position. 9356 If X is zero, the value is determined by 9357 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 9358 `ctz(x)' is equivalent to `ffs(X) - 1'. The mode of X must be M 9359 or `VOIDmode'. 9360 9361`(popcount:M X)' 9362 Represents the number of 1-bits in X, represented as an integer of 9363 mode M. The mode of X must be M or `VOIDmode'. 9364 9365`(parity:M X)' 9366 Represents the number of 1-bits modulo 2 in X, represented as an 9367 integer of mode M. The mode of X must be M or `VOIDmode'. 9368 9369`(bswap:M X)' 9370 Represents the value X with the order of bytes reversed, carried 9371 out in mode M, which must be a fixed-point machine mode. The mode 9372 of X must be M or `VOIDmode'. 9373 9374 9375File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 9376 937710.10 Comparison Operations 9378=========================== 9379 9380Comparison operators test a relation on two operands and are considered 9381to represent a machine-dependent nonzero value described by, but not 9382necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation 9383holds, or zero if it does not, for comparison operators whose results 9384have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 9385relation holds, or zero if it does not, for comparison operators that 9386return floating-point values, and a vector of either 9387`VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 9388zeros if it does not, for comparison operators that return vector 9389results. The mode of the comparison operation is independent of the 9390mode of the data being compared. If the comparison operation is being 9391tested (e.g., the first operand of an `if_then_else'), the mode must be 9392`VOIDmode'. 9393 9394 There are two ways that comparison operations may be used. The 9395comparison operators may be used to compare the condition codes `(cc0)' 9396against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 9397actually refers to the result of the preceding instruction in which the 9398condition codes were set. The instruction setting the condition code 9399must be adjacent to the instruction using the condition code; only 9400`note' insns may separate them. 9401 9402 Alternatively, a comparison operation may directly compare two data 9403objects. The mode of the comparison is determined by the operands; they 9404must both be valid for a common machine mode. A comparison with both 9405operands constant would be invalid as the machine mode could not be 9406deduced from it, but such a comparison should never exist in RTL due to 9407constant folding. 9408 9409 In the example above, if `(cc0)' were last set to `(compare X Y)', the 9410comparison operation is identical to `(eq X Y)'. Usually only one style 9411of comparisons is supported on a particular machine, but the combine 9412pass will try to merge the operations to produce the `eq' shown in case 9413it exists in the context of the particular insn involved. 9414 9415 Inequality comparisons come in two flavors, signed and unsigned. Thus, 9416there are distinct expression codes `gt' and `gtu' for signed and 9417unsigned greater-than. These can produce different results for the same 9418pair of integer values: for example, 1 is signed greater-than -1 but not 9419unsigned greater-than, because -1 when regarded as unsigned is actually 9420`0xffffffff' which is greater than 1. 9421 9422 The signed comparisons are also used for floating point values. 9423Floating point comparisons are distinguished by the machine modes of 9424the operands. 9425 9426`(eq:M X Y)' 9427 `STORE_FLAG_VALUE' if the values represented by X and Y are equal, 9428 otherwise 0. 9429 9430`(ne:M X Y)' 9431 `STORE_FLAG_VALUE' if the values represented by X and Y are not 9432 equal, otherwise 0. 9433 9434`(gt:M X Y)' 9435 `STORE_FLAG_VALUE' if the X is greater than Y. If they are 9436 fixed-point, the comparison is done in a signed sense. 9437 9438`(gtu:M X Y)' 9439 Like `gt' but does unsigned comparison, on fixed-point numbers 9440 only. 9441 9442`(lt:M X Y)' 9443`(ltu:M X Y)' 9444 Like `gt' and `gtu' but test for "less than". 9445 9446`(ge:M X Y)' 9447`(geu:M X Y)' 9448 Like `gt' and `gtu' but test for "greater than or equal". 9449 9450`(le:M X Y)' 9451`(leu:M X Y)' 9452 Like `gt' and `gtu' but test for "less than or equal". 9453 9454`(if_then_else COND THEN ELSE)' 9455 This is not a comparison operation but is listed here because it is 9456 always used in conjunction with a comparison operation. To be 9457 precise, COND is a comparison expression. This expression 9458 represents a choice, according to COND, between the value 9459 represented by THEN and the one represented by ELSE. 9460 9461 On most machines, `if_then_else' expressions are valid only to 9462 express conditional jumps. 9463 9464`(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 9465 Similar to `if_then_else', but more general. Each of TEST1, 9466 TEST2, ... is performed in turn. The result of this expression is 9467 the VALUE corresponding to the first nonzero test, or DEFAULT if 9468 none of the tests are nonzero expressions. 9469 9470 This is currently not valid for instruction patterns and is 9471 supported only for insn attributes. *Note Insn Attributes::. 9472 9473 9474File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 9475 947610.11 Bit-Fields 9477================ 9478 9479Special expression codes exist to represent bit-field instructions. 9480 9481`(sign_extract:M LOC SIZE POS)' 9482 This represents a reference to a sign-extended bit-field contained 9483 or starting in LOC (a memory or register reference). The bit-field 9484 is SIZE bits wide and starts at bit POS. The compilation option 9485 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 9486 from. 9487 9488 If LOC is in memory, its mode must be a single-byte integer mode. 9489 If LOC is in a register, the mode to use is specified by the 9490 operand of the `insv' or `extv' pattern (*note Standard Names::) 9491 and is usually a full-word integer mode, which is the default if 9492 none is specified. 9493 9494 The mode of POS is machine-specific and is also specified in the 9495 `insv' or `extv' pattern. 9496 9497 The mode M is the same as the mode that would be used for LOC if 9498 it were a register. 9499 9500 A `sign_extract' can not appear as an lvalue, or part thereof, in 9501 RTL. 9502 9503`(zero_extract:M LOC SIZE POS)' 9504 Like `sign_extract' but refers to an unsigned or zero-extended 9505 bit-field. The same sequence of bits are extracted, but they are 9506 filled to an entire word with zeros instead of by sign-extension. 9507 9508 Unlike `sign_extract', this type of expressions can be lvalues in 9509 RTL; they may appear on the left side of an assignment, indicating 9510 insertion of a value into the specified bit-field. 9511 9512 9513File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 9514 951510.12 Vector Operations 9516======================= 9517 9518All normal RTL expressions can be used with vector modes; they are 9519interpreted as operating on each part of the vector independently. 9520Additionally, there are a few new expressions to describe specific 9521vector operations. 9522 9523`(vec_merge:M VEC1 VEC2 ITEMS)' 9524 This describes a merge operation between two vectors. The result 9525 is a vector of mode M; its elements are selected from either VEC1 9526 or VEC2. Which elements are selected is described by ITEMS, which 9527 is a bit mask represented by a `const_int'; a zero bit indicates 9528 the corresponding element in the result vector is taken from VEC2 9529 while a set bit indicates it is taken from VEC1. 9530 9531`(vec_select:M VEC1 SELECTION)' 9532 This describes an operation that selects parts of a vector. VEC1 9533 is the source vector, and SELECTION is a `parallel' that contains a 9534 `const_int' for each of the subparts of the result vector, giving 9535 the number of the source subpart that should be stored into it. 9536 The result mode M is either the submode for a single element of 9537 VEC1 (if only one subpart is selected), or another vector mode 9538 with that element submode (if multiple subparts are selected). 9539 9540`(vec_concat:M X1 X2)' 9541 Describes a vector concat operation. The result is a 9542 concatenation of the vectors or scalars X1 and X2; its length is 9543 the sum of the lengths of the two inputs. 9544 9545`(vec_duplicate:M X)' 9546 This operation converts a scalar into a vector or a small vector 9547 into a larger one by duplicating the input values. The output 9548 vector mode must have the same submodes as the input vector mode 9549 or the scalar modes, and the number of output parts must be an 9550 integer multiple of the number of input parts. 9551 9552 9553 9554File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 9555 955610.13 Conversions 9557================= 9558 9559All conversions between machine modes must be represented by explicit 9560conversion operations. For example, an expression which is the sum of 9561a byte and a full word cannot be written as `(plus:SI (reg:QI 34) 9562(reg:SI 80))' because the `plus' operation requires two operands of the 9563same machine mode. Therefore, the byte-sized operand is enclosed in a 9564conversion operation, as in 9565 9566 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 9567 9568 The conversion operation is not a mere placeholder, because there may 9569be more than one way of converting from a given starting mode to the 9570desired final mode. The conversion operation code says how to do it. 9571 9572 For all conversion operations, X must not be `VOIDmode' because the 9573mode in which to do the conversion would not be known. The conversion 9574must either be done at compile-time or X must be placed into a register. 9575 9576`(sign_extend:M X)' 9577 Represents the result of sign-extending the value X to machine 9578 mode M. M must be a fixed-point mode and X a fixed-point value of 9579 a mode narrower than M. 9580 9581`(zero_extend:M X)' 9582 Represents the result of zero-extending the value X to machine 9583 mode M. M must be a fixed-point mode and X a fixed-point value of 9584 a mode narrower than M. 9585 9586`(float_extend:M X)' 9587 Represents the result of extending the value X to machine mode M. 9588 M must be a floating point mode and X a floating point value of a 9589 mode narrower than M. 9590 9591`(truncate:M X)' 9592 Represents the result of truncating the value X to machine mode M. 9593 M must be a fixed-point mode and X a fixed-point value of a mode 9594 wider than M. 9595 9596`(ss_truncate:M X)' 9597 Represents the result of truncating the value X to machine mode M, 9598 using signed saturation in the case of overflow. Both M and the 9599 mode of X must be fixed-point modes. 9600 9601`(us_truncate:M X)' 9602 Represents the result of truncating the value X to machine mode M, 9603 using unsigned saturation in the case of overflow. Both M and the 9604 mode of X must be fixed-point modes. 9605 9606`(float_truncate:M X)' 9607 Represents the result of truncating the value X to machine mode M. 9608 M must be a floating point mode and X a floating point value of a 9609 mode wider than M. 9610 9611`(float:M X)' 9612 Represents the result of converting fixed point value X, regarded 9613 as signed, to floating point mode M. 9614 9615`(unsigned_float:M X)' 9616 Represents the result of converting fixed point value X, regarded 9617 as unsigned, to floating point mode M. 9618 9619`(fix:M X)' 9620 When M is a floating-point mode, represents the result of 9621 converting floating point value X (valid for mode M) to an 9622 integer, still represented in floating point mode M, by rounding 9623 towards zero. 9624 9625 When M is a fixed-point mode, represents the result of converting 9626 floating point value X to mode M, regarded as signed. How 9627 rounding is done is not specified, so this operation may be used 9628 validly in compiling C code only for integer-valued operands. 9629 9630`(unsigned_fix:M X)' 9631 Represents the result of converting floating point value X to 9632 fixed point mode M, regarded as unsigned. How rounding is done is 9633 not specified. 9634 9635`(fract_convert:M X)' 9636 Represents the result of converting fixed-point value X to 9637 fixed-point mode M, signed integer value X to fixed-point mode M, 9638 floating-point value X to fixed-point mode M, fixed-point value X 9639 to integer mode M regarded as signed, or fixed-point value X to 9640 floating-point mode M. When overflows or underflows happen, the 9641 results are undefined. 9642 9643`(sat_fract:M X)' 9644 Represents the result of converting fixed-point value X to 9645 fixed-point mode M, signed integer value X to fixed-point mode M, 9646 or floating-point value X to fixed-point mode M. When overflows 9647 or underflows happen, the results are saturated to the maximum or 9648 the minimum. 9649 9650`(unsigned_fract_convert:M X)' 9651 Represents the result of converting fixed-point value X to integer 9652 mode M regarded as unsigned, or unsigned integer value X to 9653 fixed-point mode M. When overflows or underflows happen, the 9654 results are undefined. 9655 9656`(unsigned_sat_fract:M X)' 9657 Represents the result of converting unsigned integer value X to 9658 fixed-point mode M. When overflows or underflows happen, the 9659 results are saturated to the maximum or the minimum. 9660 9661 9662File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 9663 966410.14 Declarations 9665================== 9666 9667Declaration expression codes do not represent arithmetic operations but 9668rather state assertions about their operands. 9669 9670`(strict_low_part (subreg:M (reg:N R) 0))' 9671 This expression code is used in only one context: as the 9672 destination operand of a `set' expression. In addition, the 9673 operand of this expression must be a non-paradoxical `subreg' 9674 expression. 9675 9676 The presence of `strict_low_part' says that the part of the 9677 register which is meaningful in mode N, but is not part of mode M, 9678 is not to be altered. Normally, an assignment to such a subreg is 9679 allowed to have undefined effects on the rest of the register when 9680 M is less than a word. 9681 9682 9683File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 9684 968510.15 Side Effect Expressions 9686============================= 9687 9688The expression codes described so far represent values, not actions. 9689But machine instructions never produce values; they are meaningful only 9690for their side effects on the state of the machine. Special expression 9691codes are used to represent side effects. 9692 9693 The body of an instruction is always one of these side effect codes; 9694the codes described above, which represent values, appear only as the 9695operands of these. 9696 9697`(set LVAL X)' 9698 Represents the action of storing the value of X into the place 9699 represented by LVAL. LVAL must be an expression representing a 9700 place that can be stored in: `reg' (or `subreg', `strict_low_part' 9701 or `zero_extract'), `mem', `pc', `parallel', or `cc0'. 9702 9703 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then 9704 X must be valid for that mode. 9705 9706 If LVAL is a `reg' whose machine mode is less than the full width 9707 of the register, then it means that the part of the register 9708 specified by the machine mode is given the specified value and the 9709 rest of the register receives an undefined value. Likewise, if 9710 LVAL is a `subreg' whose machine mode is narrower than the mode of 9711 the register, the rest of the register can be changed in an 9712 undefined way. 9713 9714 If LVAL is a `strict_low_part' of a subreg, then the part of the 9715 register specified by the machine mode of the `subreg' is given 9716 the value X and the rest of the register is not changed. 9717 9718 If LVAL is a `zero_extract', then the referenced part of the 9719 bit-field (a memory or register reference) specified by the 9720 `zero_extract' is given the value X and the rest of the bit-field 9721 is not changed. Note that `sign_extract' can not appear in LVAL. 9722 9723 If LVAL is `(cc0)', it has no machine mode, and X may be either a 9724 `compare' expression or a value that may have any mode. The 9725 latter case represents a "test" instruction. The expression `(set 9726 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) 9727 (const_int 0)))'. Use the former expression to save space during 9728 the compilation. 9729 9730 If LVAL is a `parallel', it is used to represent the case of a 9731 function returning a structure in multiple registers. Each element 9732 of the `parallel' is an `expr_list' whose first operand is a `reg' 9733 and whose second operand is a `const_int' representing the offset 9734 (in bytes) into the structure at which the data in that register 9735 corresponds. The first element may be null to indicate that the 9736 structure is also passed partly in memory. 9737 9738 If LVAL is `(pc)', we have a jump instruction, and the 9739 possibilities for X are very limited. It may be a `label_ref' 9740 expression (unconditional jump). It may be an `if_then_else' 9741 (conditional jump), in which case either the second or the third 9742 operand must be `(pc)' (for the case which does not jump) and the 9743 other of the two must be a `label_ref' (for the case which does 9744 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may 9745 be a `reg' or a `mem'; these unusual patterns are used to 9746 represent jumps through branch tables. 9747 9748 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not 9749 be `VOIDmode' and the mode of X must be valid for the mode of LVAL. 9750 9751 LVAL is customarily accessed with the `SET_DEST' macro and X with 9752 the `SET_SRC' macro. 9753 9754`(return)' 9755 As the sole expression in a pattern, represents a return from the 9756 current function, on machines where this can be done with one 9757 instruction, such as VAXen. On machines where a multi-instruction 9758 "epilogue" must be executed in order to return from the function, 9759 returning is done by jumping to a label which precedes the 9760 epilogue, and the `return' expression code is never used. 9761 9762 Inside an `if_then_else' expression, represents the value to be 9763 placed in `pc' to return to the caller. 9764 9765 Note that an insn pattern of `(return)' is logically equivalent to 9766 `(set (pc) (return))', but the latter form is never used. 9767 9768`(simple_return)' 9769 Like `(return)', but truly represents only a function return, while 9770 `(return)' may represent an insn that also performs other functions 9771 of the function epilogue. Like `(return)', this may also occur in 9772 conditional jumps. 9773 9774`(call FUNCTION NARGS)' 9775 Represents a function call. FUNCTION is a `mem' expression whose 9776 address is the address of the function to be called. NARGS is an 9777 expression which can be used for two purposes: on some machines it 9778 represents the number of bytes of stack argument; on others, it 9779 represents the number of argument registers. 9780 9781 Each machine has a standard machine mode which FUNCTION must have. 9782 The machine description defines macro `FUNCTION_MODE' to expand 9783 into the requisite mode name. The purpose of this mode is to 9784 specify what kind of addressing is allowed, on machines where the 9785 allowed kinds of addressing depend on the machine mode being 9786 addressed. 9787 9788`(clobber X)' 9789 Represents the storing or possible storing of an unpredictable, 9790 undescribed value into X, which must be a `reg', `scratch', 9791 `parallel' or `mem' expression. 9792 9793 One place this is used is in string instructions that store 9794 standard values into particular hard registers. It may not be 9795 worth the trouble to describe the values that are stored, but it 9796 is essential to inform the compiler that the registers will be 9797 altered, lest it attempt to keep data in them across the string 9798 instruction. 9799 9800 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it 9801 means that all memory locations must be presumed clobbered. If X 9802 is a `parallel', it has the same meaning as a `parallel' in a 9803 `set' expression. 9804 9805 Note that the machine description classifies certain hard 9806 registers as "call-clobbered". All function call instructions are 9807 assumed by default to clobber these registers, so there is no need 9808 to use `clobber' expressions to indicate this fact. Also, each 9809 function call is assumed to have the potential to alter any memory 9810 location, unless the function is declared `const'. 9811 9812 If the last group of expressions in a `parallel' are each a 9813 `clobber' expression whose arguments are `reg' or `match_scratch' 9814 (*note RTL Template::) expressions, the combiner phase can add the 9815 appropriate `clobber' expressions to an insn it has constructed 9816 when doing so will cause a pattern to be matched. 9817 9818 This feature can be used, for example, on a machine that whose 9819 multiply and add instructions don't use an MQ register but which 9820 has an add-accumulate instruction that does clobber the MQ 9821 register. Similarly, a combined instruction might require a 9822 temporary register while the constituent instructions might not. 9823 9824 When a `clobber' expression for a register appears inside a 9825 `parallel' with other side effects, the register allocator 9826 guarantees that the register is unoccupied both before and after 9827 that insn if it is a hard register clobber. For pseudo-register 9828 clobber, the register allocator and the reload pass do not assign 9829 the same hard register to the clobber and the input operands if 9830 there is an insn alternative containing the `&' constraint (*note 9831 Modifiers::) for the clobber and the hard register is in register 9832 classes of the clobber in the alternative. You can clobber either 9833 a specific hard register, a pseudo register, or a `scratch' 9834 expression; in the latter two cases, GCC will allocate a hard 9835 register that is available there for use as a temporary. 9836 9837 For instructions that require a temporary register, you should use 9838 `scratch' instead of a pseudo-register because this will allow the 9839 combiner phase to add the `clobber' when required. You do this by 9840 coding (`clobber' (`match_scratch' ...)). If you do clobber a 9841 pseudo register, use one which appears nowhere else--generate a 9842 new one each time. Otherwise, you may confuse CSE. 9843 9844 There is one other known use for clobbering a pseudo register in a 9845 `parallel': when one of the input operands of the insn is also 9846 clobbered by the insn. In this case, using the same pseudo 9847 register in the clobber and elsewhere in the insn produces the 9848 expected results. 9849 9850`(use X)' 9851 Represents the use of the value of X. It indicates that the value 9852 in X at this point in the program is needed, even though it may 9853 not be apparent why this is so. Therefore, the compiler will not 9854 attempt to delete previous instructions whose only effect is to 9855 store a value in X. X must be a `reg' expression. 9856 9857 In some situations, it may be tempting to add a `use' of a 9858 register in a `parallel' to describe a situation where the value 9859 of a special register will modify the behavior of the instruction. 9860 A hypothetical example might be a pattern for an addition that can 9861 either wrap around or use saturating addition depending on the 9862 value of a special control register: 9863 9864 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 9865 (reg:SI 4)] 0)) 9866 (use (reg:SI 1))]) 9867 9868 This will not work, several of the optimizers only look at 9869 expressions locally; it is very likely that if you have multiple 9870 insns with identical inputs to the `unspec', they will be 9871 optimized away even if register 1 changes in between. 9872 9873 This means that `use' can _only_ be used to describe that the 9874 register is live. You should think twice before adding `use' 9875 statements, more often you will want to use `unspec' instead. The 9876 `use' RTX is most commonly useful to describe that a fixed 9877 register is implicitly used in an insn. It is also safe to use in 9878 patterns where the compiler knows for other reasons that the result 9879 of the whole pattern is variable, such as `movmemM' or `call' 9880 patterns. 9881 9882 During the reload phase, an insn that has a `use' as pattern can 9883 carry a reg_equal note. These `use' insns will be deleted before 9884 the reload phase exits. 9885 9886 During the delayed branch scheduling phase, X may be an insn. 9887 This indicates that X previously was located at this place in the 9888 code and its data dependencies need to be taken into account. 9889 These `use' insns will be deleted before the delayed branch 9890 scheduling phase exits. 9891 9892`(parallel [X0 X1 ...])' 9893 Represents several side effects performed in parallel. The square 9894 brackets stand for a vector; the operand of `parallel' is a vector 9895 of expressions. X0, X1 and so on are individual side effect 9896 expressions--expressions of code `set', `call', `return', 9897 `simple_return', `clobber' or `use'. 9898 9899 "In parallel" means that first all the values used in the 9900 individual side-effects are computed, and second all the actual 9901 side-effects are performed. For example, 9902 9903 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 9904 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 9905 9906 says unambiguously that the values of hard register 1 and the 9907 memory location addressed by it are interchanged. In both places 9908 where `(reg:SI 1)' appears as a memory address it refers to the 9909 value in register 1 _before_ the execution of the insn. 9910 9911 It follows that it is _incorrect_ to use `parallel' and expect the 9912 result of one `set' to be available for the next one. For 9913 example, people sometimes attempt to represent a jump-if-zero 9914 instruction this way: 9915 9916 (parallel [(set (cc0) (reg:SI 34)) 9917 (set (pc) (if_then_else 9918 (eq (cc0) (const_int 0)) 9919 (label_ref ...) 9920 (pc)))]) 9921 9922 But this is incorrect, because it says that the jump condition 9923 depends on the condition code value _before_ this instruction, not 9924 on the new value that is set by this instruction. 9925 9926 Peephole optimization, which takes place together with final 9927 assembly code output, can produce insns whose patterns consist of 9928 a `parallel' whose elements are the operands needed to output the 9929 resulting assembler code--often `reg', `mem' or constant 9930 expressions. This would not be well-formed RTL at any other stage 9931 in compilation, but it is ok then because no further optimization 9932 remains to be done. However, the definition of the macro 9933 `NOTICE_UPDATE_CC', if any, must deal with such insns if you 9934 define any peephole optimizations. 9935 9936`(cond_exec [COND EXPR])' 9937 Represents a conditionally executed expression. The EXPR is 9938 executed only if the COND is nonzero. The COND expression must 9939 not have side-effects, but the EXPR may very well have 9940 side-effects. 9941 9942`(sequence [INSNS ...])' 9943 Represents a sequence of insns. Each of the INSNS that appears in 9944 the vector is suitable for appearing in the chain of insns, so it 9945 must be an `insn', `jump_insn', `call_insn', `code_label', 9946 `barrier' or `note'. 9947 9948 A `sequence' RTX is never placed in an actual insn during RTL 9949 generation. It represents the sequence of insns that result from a 9950 `define_expand' _before_ those insns are passed to `emit_insn' to 9951 insert them in the chain of insns. When actually inserted, the 9952 individual sub-insns are separated out and the `sequence' is 9953 forgotten. 9954 9955 After delay-slot scheduling is completed, an insn and all the 9956 insns that reside in its delay slots are grouped together into a 9957 `sequence'. The insn requiring the delay slot is the first insn 9958 in the vector; subsequent insns are to be placed in the delay slot. 9959 9960 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 9961 indicate that a branch insn should be used that will conditionally 9962 annul the effect of the insns in the delay slots. In such a case, 9963 `INSN_FROM_TARGET_P' indicates that the insn is from the target of 9964 the branch and should be executed only if the branch is taken; 9965 otherwise the insn should be executed only if the branch is not 9966 taken. *Note Delay Slots::. 9967 9968 These expression codes appear in place of a side effect, as the body of 9969an insn, though strictly speaking they do not always describe side 9970effects as such: 9971 9972`(asm_input S)' 9973 Represents literal assembler code as described by the string S. 9974 9975`(unspec [OPERANDS ...] INDEX)' 9976`(unspec_volatile [OPERANDS ...] INDEX)' 9977 Represents a machine-specific operation on OPERANDS. INDEX 9978 selects between multiple machine-specific operations. 9979 `unspec_volatile' is used for volatile operations and operations 9980 that may trap; `unspec' is used for other operations. 9981 9982 These codes may appear inside a `pattern' of an insn, inside a 9983 `parallel', or inside an expression. 9984 9985`(addr_vec:M [LR0 LR1 ...])' 9986 Represents a table of jump addresses. The vector elements LR0, 9987 etc., are `label_ref' expressions. The mode M specifies how much 9988 space is given to each address; normally M would be `Pmode'. 9989 9990`(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 9991 Represents a table of jump addresses expressed as offsets from 9992 BASE. The vector elements LR0, etc., are `label_ref' expressions 9993 and so is BASE. The mode M specifies how much space is given to 9994 each address-difference. MIN and MAX are set up by branch 9995 shortening and hold a label with a minimum and a maximum address, 9996 respectively. FLAGS indicates the relative position of BASE, MIN 9997 and MAX to the containing insn and of MIN and MAX to BASE. See 9998 rtl.def for details. 9999 10000`(prefetch:M ADDR RW LOCALITY)' 10001 Represents prefetch of memory at address ADDR. Operand RW is 1 if 10002 the prefetch is for data to be written, 0 otherwise; targets that 10003 do not support write prefetches should treat this as a normal 10004 prefetch. Operand LOCALITY specifies the amount of temporal 10005 locality; 0 if there is none or 1, 2, or 3 for increasing levels 10006 of temporal locality; targets that do not support locality hints 10007 should ignore this. 10008 10009 This insn is used to minimize cache-miss latency by moving data 10010 into a cache before it is accessed. It should use only 10011 non-faulting data prefetch instructions. 10012 10013 10014File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 10015 1001610.16 Embedded Side-Effects on Addresses 10017======================================== 10018 10019Six special side-effect expression codes appear as memory addresses. 10020 10021`(pre_dec:M X)' 10022 Represents the side effect of decrementing X by a standard amount 10023 and represents also the value that X has after being decremented. 10024 X must be a `reg' or `mem', but most machines allow only a `reg'. 10025 M must be the machine mode for pointers on the machine in use. 10026 The amount X is decremented by is the length in bytes of the 10027 machine mode of the containing memory reference of which this 10028 expression serves as the address. Here is an example of its use: 10029 10030 (mem:DF (pre_dec:SI (reg:SI 39))) 10031 10032 This says to decrement pseudo register 39 by the length of a 10033 `DFmode' value and use the result to address a `DFmode' value. 10034 10035`(pre_inc:M X)' 10036 Similar, but specifies incrementing X instead of decrementing it. 10037 10038`(post_dec:M X)' 10039 Represents the same side effect as `pre_dec' but a different 10040 value. The value represented here is the value X has before being 10041 decremented. 10042 10043`(post_inc:M X)' 10044 Similar, but specifies incrementing X instead of decrementing it. 10045 10046`(post_modify:M X Y)' 10047 Represents the side effect of setting X to Y and represents X 10048 before X is modified. X must be a `reg' or `mem', but most 10049 machines allow only a `reg'. M must be the machine mode for 10050 pointers on the machine in use. 10051 10052 The expression Y must be one of three forms: `(plus:M X Z)', 10053 `(minus:M X Z)', or `(plus:M X I)', where Z is an index register 10054 and I is a constant. 10055 10056 Here is an example of its use: 10057 10058 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 10059 (reg:SI 48)))) 10060 10061 This says to modify pseudo register 42 by adding the contents of 10062 pseudo register 48 to it, after the use of what ever 42 points to. 10063 10064`(pre_modify:M X EXPR)' 10065 Similar except side effects happen before the use. 10066 10067 These embedded side effect expressions must be used with care. 10068Instruction patterns may not use them. Until the `flow' pass of the 10069compiler, they may occur only to represent pushes onto the stack. The 10070`flow' pass finds cases where registers are incremented or decremented 10071in one instruction and used as an address shortly before or after; 10072these cases are then transformed to use pre- or post-increment or 10073-decrement. 10074 10075 If a register used as the operand of these expressions is used in 10076another address in an insn, the original value of the register is used. 10077Uses of the register outside of an address are not permitted within the 10078same insn as a use in an embedded side effect expression because such 10079insns behave differently on different machines and hence must be treated 10080as ambiguous and disallowed. 10081 10082 An instruction that can be represented with an embedded side effect 10083could also be represented using `parallel' containing an additional 10084`set' to describe how the address register is altered. This is not 10085done because machines that allow these operations at all typically 10086allow them wherever a memory address is called for. Describing them as 10087additional parallel stores would require doubling the number of entries 10088in the machine description. 10089 10090 10091File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 10092 1009310.17 Assembler Instructions as Expressions 10094=========================================== 10095 10096The RTX code `asm_operands' represents a value produced by a 10097user-specified assembler instruction. It is used to represent an `asm' 10098statement with arguments. An `asm' statement with a single output 10099operand, like this: 10100 10101 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 10102 10103is represented using a single `asm_operands' RTX which represents the 10104value that is stored in `outputvar': 10105 10106 (set RTX-FOR-OUTPUTVAR 10107 (asm_operands "foo %1,%2,%0" "a" 0 10108 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 10109 [(asm_input:M1 "g") 10110 (asm_input:M2 "di")])) 10111 10112Here the operands of the `asm_operands' RTX are the assembler template 10113string, the output-operand's constraint, the index-number of the output 10114operand among the output operands specified, a vector of input operand 10115RTX's, and a vector of input-operand modes and constraints. The mode 10116M1 is the mode of the sum `x+y'; M2 is that of `*z'. 10117 10118 When an `asm' statement has multiple output values, its insn has 10119several such `set' RTX's inside of a `parallel'. Each `set' contains 10120an `asm_operands'; all of these share the same assembler template and 10121vectors, but each contains the constraint for the respective output 10122operand. They are also distinguished by the output-operand index 10123number, which is 0, 1, ... for successive output operands. 10124 10125 10126File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 10127 1012810.18 Variable Location Debug Information in RTL 10129================================================ 10130 10131Variable tracking relies on `MEM_EXPR' and `REG_EXPR' annotations to 10132determine what user variables memory and register references refer to. 10133 10134 Variable tracking at assignments uses these notes only when they refer 10135to variables that live at fixed locations (e.g., addressable variables, 10136global non-automatic variables). For variables whose location may 10137vary, it relies on the following types of notes. 10138 10139`(var_location:MODE VAR EXP STAT)' 10140 Binds variable `var', a tree, to value EXP, an RTL expression. It 10141 appears only in `NOTE_INSN_VAR_LOCATION' and `DEBUG_INSN's, with 10142 slightly different meanings. MODE, if present, represents the 10143 mode of EXP, which is useful if it is a modeless expression. STAT 10144 is only meaningful in notes, indicating whether the variable is 10145 known to be initialized or uninitialized. 10146 10147`(debug_expr:MODE DECL)' 10148 Stands for the value bound to the `DEBUG_EXPR_DECL' DECL, that 10149 points back to it, within value expressions in `VAR_LOCATION' 10150 nodes. 10151 10152 10153 10154File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 10155 1015610.19 Insns 10157=========== 10158 10159The RTL representation of the code for a function is a doubly-linked 10160chain of objects called "insns". Insns are expressions with special 10161codes that are used for no other purpose. Some insns are actual 10162instructions; others represent dispatch tables for `switch' statements; 10163others represent labels to jump to or various sorts of declarative 10164information. 10165 10166 In addition to its own specific data, each insn must have a unique 10167id-number that distinguishes it from all other insns in the current 10168function (after delayed branch scheduling, copies of an insn with the 10169same id-number may be present in multiple places in a function, but 10170these copies will always be identical and will only appear inside a 10171`sequence'), and chain pointers to the preceding and following insns. 10172These three fields occupy the same position in every insn, independent 10173of the expression code of the insn. They could be accessed with `XEXP' 10174and `XINT', but instead three special macros are always used: 10175 10176`INSN_UID (I)' 10177 Accesses the unique id of insn I. 10178 10179`PREV_INSN (I)' 10180 Accesses the chain pointer to the insn preceding I. If I is the 10181 first insn, this is a null pointer. 10182 10183`NEXT_INSN (I)' 10184 Accesses the chain pointer to the insn following I. If I is the 10185 last insn, this is a null pointer. 10186 10187 The first insn in the chain is obtained by calling `get_insns'; the 10188last insn is the result of calling `get_last_insn'. Within the chain 10189delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must 10190always correspond: if INSN is not the first insn, 10191 10192 NEXT_INSN (PREV_INSN (INSN)) == INSN 10193 10194is always true and if INSN is not the last insn, 10195 10196 PREV_INSN (NEXT_INSN (INSN)) == INSN 10197 10198is always true. 10199 10200 After delay slot scheduling, some of the insns in the chain might be 10201`sequence' expressions, which contain a vector of insns. The value of 10202`NEXT_INSN' in all but the last of these insns is the next insn in the 10203vector; the value of `NEXT_INSN' of the last insn in the vector is the 10204same as the value of `NEXT_INSN' for the `sequence' in which it is 10205contained. Similar rules apply for `PREV_INSN'. 10206 10207 This means that the above invariants are not necessarily true for insns 10208inside `sequence' expressions. Specifically, if INSN is the first insn 10209in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing 10210the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN 10211(INSN))' if INSN is the last insn in the `sequence' expression. You 10212can use these expressions to find the containing `sequence' expression. 10213 10214 Every insn has one of the following expression codes: 10215 10216`insn' 10217 The expression code `insn' is used for instructions that do not 10218 jump and do not do function calls. `sequence' expressions are 10219 always contained in insns with code `insn' even if one of those 10220 insns should jump or do function calls. 10221 10222 Insns with code `insn' have four additional fields beyond the three 10223 mandatory ones listed above. These four are described in a table 10224 below. 10225 10226`jump_insn' 10227 The expression code `jump_insn' is used for instructions that may 10228 jump (or, more generally, may contain `label_ref' expressions to 10229 which `pc' can be set in that instruction). If there is an 10230 instruction to return from the current function, it is recorded as 10231 a `jump_insn'. 10232 10233 `jump_insn' insns have the same extra fields as `insn' insns, 10234 accessed in the same way and in addition contain a field 10235 `JUMP_LABEL' which is defined once jump optimization has completed. 10236 10237 For simple conditional and unconditional jumps, this field contains 10238 the `code_label' to which this insn will (possibly conditionally) 10239 branch. In a more complex jump, `JUMP_LABEL' records one of the 10240 labels that the insn refers to; other jump target labels are 10241 recorded as `REG_LABEL_TARGET' notes. The exception is `addr_vec' 10242 and `addr_diff_vec', where `JUMP_LABEL' is `NULL_RTX' and the only 10243 way to find the labels is to scan the entire body of the insn. 10244 10245 Return insns count as jumps, but since they do not refer to any 10246 labels, their `JUMP_LABEL' is `NULL_RTX'. 10247 10248`call_insn' 10249 The expression code `call_insn' is used for instructions that may 10250 do function calls. It is important to distinguish these 10251 instructions because they imply that certain registers and memory 10252 locations may be altered unpredictably. 10253 10254 `call_insn' insns have the same extra fields as `insn' insns, 10255 accessed in the same way and in addition contain a field 10256 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 10257 `expr_list' expressions) containing `use', `clobber' and sometimes 10258 `set' expressions that denote hard registers and `mem's used or 10259 clobbered by the called function. 10260 10261 A `mem' generally points to a stack slot in which arguments passed 10262 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 10263 Register Arguments.) are stored. If the argument is caller-copied 10264 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 10265 will be mentioned in `clobber' and `use' entries; if it's 10266 callee-copied, only a `use' will appear, and the `mem' may point 10267 to addresses that are not stack slots. 10268 10269 Registers occurring inside a `clobber' in this list augment 10270 registers specified in `CALL_USED_REGISTERS' (*note Register 10271 Basics::). 10272 10273 If the list contains a `set' involving two registers, it indicates 10274 that the function returns one of its arguments. Such a `set' may 10275 look like a no-op if the same register holds the argument and the 10276 return value. 10277 10278`code_label' 10279 A `code_label' insn represents a label that a jump insn can jump 10280 to. It contains two special fields of data in addition to the 10281 three standard ones. `CODE_LABEL_NUMBER' is used to hold the 10282 "label number", a number that identifies this label uniquely among 10283 all the labels in the compilation (not just in the current 10284 function). Ultimately, the label is represented in the assembler 10285 output as an assembler label, usually of the form `LN' where N is 10286 the label number. 10287 10288 When a `code_label' appears in an RTL expression, it normally 10289 appears within a `label_ref' which represents the address of the 10290 label, as a number. 10291 10292 Besides as a `code_label', a label can also be represented as a 10293 `note' of type `NOTE_INSN_DELETED_LABEL'. 10294 10295 The field `LABEL_NUSES' is only defined once the jump optimization 10296 phase is completed. It contains the number of times this label is 10297 referenced in the current function. 10298 10299 The field `LABEL_KIND' differentiates four different types of 10300 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY', 10301 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels 10302 that do not have type `LABEL_NORMAL' are "alternate entry points" 10303 to the current function. These may be static (visible only in the 10304 containing translation unit), global (exposed to all translation 10305 units), or weak (global, but can be overridden by another symbol 10306 with the same name). 10307 10308 Much of the compiler treats all four kinds of label identically. 10309 Some of it needs to know whether or not a label is an alternate 10310 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is 10311 provided. It is equivalent to testing whether `LABEL_KIND (label) 10312 == LABEL_NORMAL'. The only place that cares about the distinction 10313 between static, global, and weak alternate entry points, besides 10314 the front-end code that creates them, is the function 10315 `output_alternate_entry_point', in `final.c'. 10316 10317 To set the kind of a label, use the `SET_LABEL_KIND' macro. 10318 10319`barrier' 10320 Barriers are placed in the instruction stream when control cannot 10321 flow past them. They are placed after unconditional jump 10322 instructions to indicate that the jumps are unconditional and 10323 after calls to `volatile' functions, which do not return (e.g., 10324 `exit'). They contain no information beyond the three standard 10325 fields. 10326 10327`note' 10328 `note' insns are used to represent additional debugging and 10329 declarative information. They contain two nonstandard fields, an 10330 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a 10331 string accessed with `NOTE_SOURCE_FILE'. 10332 10333 If `NOTE_LINE_NUMBER' is positive, the note represents the 10334 position of a source line and `NOTE_SOURCE_FILE' is the source 10335 file name that the line came from. These notes control generation 10336 of line number data in the assembler output. 10337 10338 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a 10339 code with one of the following values (and `NOTE_SOURCE_FILE' must 10340 contain a null pointer): 10341 10342 `NOTE_INSN_DELETED' 10343 Such a note is completely ignorable. Some passes of the 10344 compiler delete insns by altering them into notes of this 10345 kind. 10346 10347 `NOTE_INSN_DELETED_LABEL' 10348 This marks what used to be a `code_label', but was not used 10349 for other purposes than taking its address and was 10350 transformed to mark that no code jumps to it. 10351 10352 `NOTE_INSN_BLOCK_BEG' 10353 `NOTE_INSN_BLOCK_END' 10354 These types of notes indicate the position of the beginning 10355 and end of a level of scoping of variable names. They 10356 control the output of debugging information. 10357 10358 `NOTE_INSN_EH_REGION_BEG' 10359 `NOTE_INSN_EH_REGION_END' 10360 These types of notes indicate the position of the beginning 10361 and end of a level of scoping for exception handling. 10362 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note' 10363 of type `NOTE_INSN_DELETED_LABEL' is associated with the 10364 given region. 10365 10366 `NOTE_INSN_LOOP_BEG' 10367 `NOTE_INSN_LOOP_END' 10368 These types of notes indicate the position of the beginning 10369 and end of a `while' or `for' loop. They enable the loop 10370 optimizer to find loops quickly. 10371 10372 `NOTE_INSN_LOOP_CONT' 10373 Appears at the place in a loop that `continue' statements 10374 jump to. 10375 10376 `NOTE_INSN_LOOP_VTOP' 10377 This note indicates the place in a loop where the exit test 10378 begins for those loops in which the exit test has been 10379 duplicated. This position becomes another virtual start of 10380 the loop when considering loop invariants. 10381 10382 `NOTE_INSN_FUNCTION_BEG' 10383 Appears at the start of the function body, after the function 10384 prologue. 10385 10386 `NOTE_INSN_VAR_LOCATION' 10387 This note is used to generate variable location debugging 10388 information. It indicates that the user variable in its 10389 `VAR_LOCATION' operand is at the location given in the RTL 10390 expression, or holds a value that can be computed by 10391 evaluating the RTL expression from that static point in the 10392 program up to the next such note for the same user variable. 10393 10394 10395 These codes are printed symbolically when they appear in debugging 10396 dumps. 10397 10398`debug_insn' 10399 The expression code `debug_insn' is used for pseudo-instructions 10400 that hold debugging information for variable tracking at 10401 assignments (see `-fvar-tracking-assignments' option). They are 10402 the RTL representation of `GIMPLE_DEBUG' statements (*note 10403 `GIMPLE_DEBUG'::), with a `VAR_LOCATION' operand that binds a user 10404 variable tree to an RTL representation of the `value' in the 10405 corresponding statement. A `DEBUG_EXPR' in it stands for the 10406 value bound to the corresponding `DEBUG_EXPR_DECL'. 10407 10408 Throughout optimization passes, binding information is kept in 10409 pseudo-instruction form, so that, unlike notes, it gets the same 10410 treatment and adjustments that regular instructions would. It is 10411 the variable tracking pass that turns these pseudo-instructions 10412 into var location notes, analyzing control flow, value 10413 equivalences and changes to registers and memory referenced in 10414 value expressions, propagating the values of debug temporaries and 10415 determining expressions that can be used to compute the value of 10416 each user variable at as many points (ranges, actually) in the 10417 program as possible. 10418 10419 Unlike `NOTE_INSN_VAR_LOCATION', the value expression in an 10420 `INSN_VAR_LOCATION' denotes a value at that specific point in the 10421 program, rather than an expression that can be evaluated at any 10422 later point before an overriding `VAR_LOCATION' is encountered. 10423 E.g., if a user variable is bound to a `REG' and then a subsequent 10424 insn modifies the `REG', the note location would keep mapping the 10425 user variable to the register across the insn, whereas the insn 10426 location would keep the variable bound to the value, so that the 10427 variable tracking pass would emit another location note for the 10428 variable at the point in which the register is modified. 10429 10430 10431 The machine mode of an insn is normally `VOIDmode', but some phases 10432use the mode for various purposes. 10433 10434 The common subexpression elimination pass sets the mode of an insn to 10435`QImode' when it is the first insn in a block that has already been 10436processed. 10437 10438 The second Haifa scheduling pass, for targets that can multiple issue, 10439sets the mode of an insn to `TImode' when it is believed that the 10440instruction begins an issue group. That is, when the instruction 10441cannot issue simultaneously with the previous. This may be relied on 10442by later passes, in particular machine-dependent reorg. 10443 10444 Here is a table of the extra fields of `insn', `jump_insn' and 10445`call_insn' insns: 10446 10447`PATTERN (I)' 10448 An expression for the side effect performed by this insn. This 10449 must be one of the following codes: `set', `call', `use', 10450 `clobber', `return', `simple_return', `asm_input', `asm_output', 10451 `addr_vec', `addr_diff_vec', `trap_if', `unspec', 10452 `unspec_volatile', `parallel', `cond_exec', or `sequence'. If it 10453 is a `parallel', each element of the `parallel' must be one these 10454 codes, except that `parallel' expressions cannot be nested and 10455 `addr_vec' and `addr_diff_vec' are not permitted inside a 10456 `parallel' expression. 10457 10458`INSN_CODE (I)' 10459 An integer that says which pattern in the machine description 10460 matches this insn, or -1 if the matching has not yet been 10461 attempted. 10462 10463 Such matching is never attempted and this field remains -1 on an 10464 insn whose pattern consists of a single `use', `clobber', 10465 `asm_input', `addr_vec' or `addr_diff_vec' expression. 10466 10467 Matching is also never attempted on insns that result from an `asm' 10468 statement. These contain at least one `asm_operands' expression. 10469 The function `asm_noperands' returns a non-negative value for such 10470 insns. 10471 10472 In the debugging output, this field is printed as a number 10473 followed by a symbolic representation that locates the pattern in 10474 the `md' file as some small positive or negative offset from a 10475 named pattern. 10476 10477`LOG_LINKS (I)' 10478 A list (chain of `insn_list' expressions) giving information about 10479 dependencies between instructions within a basic block. Neither a 10480 jump nor a label may come between the related insns. These are 10481 only used by the schedulers and by combine. This is a deprecated 10482 data structure. Def-use and use-def chains are now preferred. 10483 10484`REG_NOTES (I)' 10485 A list (chain of `expr_list' and `insn_list' expressions) giving 10486 miscellaneous information about the insn. It is often information 10487 pertaining to the registers used in this insn. 10488 10489 The `LOG_LINKS' field of an insn is a chain of `insn_list' 10490expressions. Each of these has two operands: the first is an insn, and 10491the second is another `insn_list' expression (the next one in the 10492chain). The last `insn_list' in the chain has a null pointer as second 10493operand. The significant thing about the chain is which insns appear 10494in it (as first operands of `insn_list' expressions). Their order is 10495not significant. 10496 10497 This list is originally set up by the flow analysis pass; it is a null 10498pointer until then. Flow only adds links for those data dependencies 10499which can be used for instruction combination. For each insn, the flow 10500analysis pass adds a link to insns which store into registers values 10501that are used for the first time in this insn. 10502 10503 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS' 10504field but it includes `expr_list' expressions in addition to 10505`insn_list' expressions. There are several kinds of register notes, 10506which are distinguished by the machine mode, which in a register note 10507is really understood as being an `enum reg_note'. The first operand OP 10508of the note is data whose meaning depends on the kind of note. 10509 10510 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its 10511counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 10512register note type of X to be NEWKIND. 10513 10514 Register notes are of three classes: They may say something about an 10515input to an insn, they may say something about an output of an insn, or 10516they may create a linkage between two insns. There are also a set of 10517values that are only used in `LOG_LINKS'. 10518 10519 These register notes annotate inputs to an insn: 10520 10521`REG_DEAD' 10522 The value in OP dies in this insn; that is to say, altering the 10523 value immediately after this insn would not affect the future 10524 behavior of the program. 10525 10526 It does not follow that the register OP has no useful value after 10527 this insn since OP is not necessarily modified by this insn. 10528 Rather, no subsequent instruction uses the contents of OP. 10529 10530`REG_UNUSED' 10531 The register OP being set by this insn will not be used in a 10532 subsequent insn. This differs from a `REG_DEAD' note, which 10533 indicates that the value in an input will not be used subsequently. 10534 These two notes are independent; both may be present for the same 10535 register. 10536 10537`REG_INC' 10538 The register OP is incremented (or decremented; at this level 10539 there is no distinction) by an embedded side effect inside this 10540 insn. This means it appears in a `post_inc', `pre_inc', 10541 `post_dec' or `pre_dec' expression. 10542 10543`REG_NONNEG' 10544 The register OP is known to have a nonnegative value when this 10545 insn is reached. This is used so that decrement and branch until 10546 zero instructions, such as the m68k dbra, can be matched. 10547 10548 The `REG_NONNEG' note is added to insns only if the machine 10549 description has a `decrement_and_branch_until_zero' pattern. 10550 10551`REG_LABEL_OPERAND' 10552 This insn uses OP, a `code_label' or a `note' of type 10553 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a 10554 `jump_insn' that refers to the operand as an ordinary operand. 10555 The label may still eventually be a jump target, but if so in an 10556 indirect jump in a subsequent insn. The presence of this note 10557 allows jump optimization to be aware that OP is, in fact, being 10558 used, and flow optimization to build an accurate flow graph. 10559 10560`REG_LABEL_TARGET' 10561 This insn is a `jump_insn' but not an `addr_vec' or 10562 `addr_diff_vec'. It uses OP, a `code_label' as a direct or 10563 indirect jump target. Its purpose is similar to that of 10564 `REG_LABEL_OPERAND'. This note is only present if the insn has 10565 multiple targets; the last label in the insn (in the highest 10566 numbered insn-field) goes into the `JUMP_LABEL' field and does not 10567 have a `REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 10568 10569`REG_CROSSING_JUMP' 10570 This insn is a branching instruction (either an unconditional jump 10571 or an indirect jump) which crosses between hot and cold sections, 10572 which could potentially be very far apart in the executable. The 10573 presence of this note indicates to other optimizations that this 10574 branching instruction should not be "collapsed" into a simpler 10575 branching construct. It is used when the optimization to 10576 partition basic blocks into hot and cold sections is turned on. 10577 10578`REG_SETJMP' 10579 Appears attached to each `CALL_INSN' to `setjmp' or a related 10580 function. 10581 10582 The following notes describe attributes of outputs of an insn: 10583 10584`REG_EQUIV' 10585`REG_EQUAL' 10586 This note is only valid on an insn that sets only one register and 10587 indicates that that register will be equal to OP at run time; the 10588 scope of this equivalence differs between the two types of notes. 10589 The value which the insn explicitly copies into the register may 10590 look different from OP, but they will be equal at run time. If the 10591 output of the single `set' is a `strict_low_part' expression, the 10592 note refers to the register that is contained in `SUBREG_REG' of 10593 the `subreg' expression. 10594 10595 For `REG_EQUIV', the register is equivalent to OP throughout the 10596 entire function, and could validly be replaced in all its 10597 occurrences by OP. ("Validly" here refers to the data flow of the 10598 program; simple replacement may make some insns invalid.) For 10599 example, when a constant is loaded into a register that is never 10600 assigned any other value, this kind of note is used. 10601 10602 When a parameter is copied into a pseudo-register at entry to a 10603 function, a note of this kind records that the register is 10604 equivalent to the stack slot where the parameter was passed. 10605 Although in this case the register may be set by other insns, it 10606 is still valid to replace the register by the stack slot 10607 throughout the function. 10608 10609 A `REG_EQUIV' note is also used on an instruction which copies a 10610 register parameter into a pseudo-register at entry to a function, 10611 if there is a stack slot where that parameter could be stored. 10612 Although other insns may set the pseudo-register, it is valid for 10613 the compiler to replace the pseudo-register by stack slot 10614 throughout the function, provided the compiler ensures that the 10615 stack slot is properly initialized by making the replacement in 10616 the initial copy instruction as well. This is used on machines 10617 for which the calling convention allocates stack space for 10618 register parameters. See `REG_PARM_STACK_SPACE' in *note Stack 10619 Arguments::. 10620 10621 In the case of `REG_EQUAL', the register that is set by this insn 10622 will be equal to OP at run time at the end of this insn but not 10623 necessarily elsewhere in the function. In this case, OP is 10624 typically an arithmetic expression. For example, when a sequence 10625 of insns such as a library call is used to perform an arithmetic 10626 operation, this kind of note is attached to the insn that produces 10627 or copies the final value. 10628 10629 These two notes are used in different ways by the compiler passes. 10630 `REG_EQUAL' is used by passes prior to register allocation (such as 10631 common subexpression elimination and loop optimization) to tell 10632 them how to think of that value. `REG_EQUIV' notes are used by 10633 register allocation to indicate that there is an available 10634 substitute expression (either a constant or a `mem' expression for 10635 the location of a parameter on the stack) that may be used in 10636 place of a register if insufficient registers are available. 10637 10638 Except for stack homes for parameters, which are indicated by a 10639 `REG_EQUIV' note and are not useful to the early optimization 10640 passes and pseudo registers that are equivalent to a memory 10641 location throughout their entire life, which is not detected until 10642 later in the compilation, all equivalences are initially indicated 10643 by an attached `REG_EQUAL' note. In the early stages of register 10644 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note 10645 if OP is a constant and the insn represents the only set of its 10646 destination register. 10647 10648 Thus, compiler passes prior to register allocation need only check 10649 for `REG_EQUAL' notes and passes subsequent to register allocation 10650 need only check for `REG_EQUIV' notes. 10651 10652 These notes describe linkages between insns. They occur in pairs: one 10653insn has one of a pair of notes that points to a second insn, which has 10654the inverse note pointing back to the first insn. 10655 10656`REG_CC_SETTER' 10657`REG_CC_USER' 10658 On machines that use `cc0', the insns which set and use `cc0' set 10659 and use `cc0' are adjacent. However, when branch delay slot 10660 filling is done, this may no longer be true. In this case a 10661 `REG_CC_USER' note will be placed on the insn setting `cc0' to 10662 point to the insn using `cc0' and a `REG_CC_SETTER' note will be 10663 placed on the insn using `cc0' to point to the insn setting `cc0'. 10664 10665 These values are only used in the `LOG_LINKS' field, and indicate the 10666type of dependency that each link represents. Links which indicate a 10667data dependence (a read after write dependence) do not use any code, 10668they simply have mode `VOIDmode', and are printed without any 10669descriptive text. 10670 10671`REG_DEP_TRUE' 10672 This indicates a true dependence (a read after write dependence). 10673 10674`REG_DEP_OUTPUT' 10675 This indicates an output dependence (a write after write 10676 dependence). 10677 10678`REG_DEP_ANTI' 10679 This indicates an anti dependence (a write after read dependence). 10680 10681 10682 These notes describe information gathered from gcov profile data. They 10683are stored in the `REG_NOTES' field of an insn as an `expr_list'. 10684 10685`REG_BR_PROB' 10686 This is used to specify the ratio of branches to non-branches of a 10687 branch insn according to the profile data. The value is stored as 10688 a value between 0 and REG_BR_PROB_BASE; larger values indicate a 10689 higher probability that the branch will be taken. 10690 10691`REG_BR_PRED' 10692 These notes are found in JUMP insns after delayed branch scheduling 10693 has taken place. They indicate both the direction and the 10694 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 10695 values. 10696 10697`REG_FRAME_RELATED_EXPR' 10698 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 10699 expression is used in place of the actual insn pattern. This is 10700 done in cases where the pattern is either complex or misleading. 10701 10702 For convenience, the machine mode in an `insn_list' or `expr_list' is 10703printed using these symbolic codes in debugging dumps. 10704 10705 The only difference between the expression codes `insn_list' and 10706`expr_list' is that the first operand of an `insn_list' is assumed to 10707be an insn and is printed in debugging dumps as the insn's unique id; 10708the first operand of an `expr_list' is printed in the ordinary way as 10709an expression. 10710 10711 10712File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 10713 1071410.20 RTL Representation of Function-Call Insns 10715=============================================== 10716 10717Insns that call subroutines have the RTL expression code `call_insn'. 10718These insns must satisfy special rules, and their bodies must use a 10719special RTL expression code, `call'. 10720 10721 A `call' expression has two operands, as follows: 10722 10723 (call (mem:FM ADDR) NBYTES) 10724 10725Here NBYTES is an operand that represents the number of bytes of 10726argument data being passed to the subroutine, FM is a machine mode 10727(which must equal as the definition of the `FUNCTION_MODE' macro in the 10728machine description) and ADDR represents the address of the subroutine. 10729 10730 For a subroutine that returns no value, the `call' expression as shown 10731above is the entire body of the insn, except that the insn might also 10732contain `use' or `clobber' expressions. 10733 10734 For a subroutine that returns a value whose mode is not `BLKmode', the 10735value is returned in a hard register. If this register's number is R, 10736then the body of the call insn looks like this: 10737 10738 (set (reg:M R) 10739 (call (mem:FM ADDR) NBYTES)) 10740 10741This RTL expression makes it clear (to the optimizer passes) that the 10742appropriate register receives a useful value in this insn. 10743 10744 When a subroutine returns a `BLKmode' value, it is handled by passing 10745to the subroutine the address of a place to store the value. So the 10746call insn itself does not "return" any value, and it has the same RTL 10747form as a call that returns nothing. 10748 10749 On some machines, the call instruction itself clobbers some register, 10750for example to contain the return address. `call_insn' insns on these 10751machines should have a body which is a `parallel' that contains both 10752the `call' expression and `clobber' expressions that indicate which 10753registers are destroyed. Similarly, if the call instruction requires 10754some register other than the stack pointer that is not explicitly 10755mentioned in its RTL, a `use' subexpression should mention that 10756register. 10757 10758 Functions that are called are assumed to modify all registers listed in 10759the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::) 10760and, with the exception of `const' functions and library calls, to 10761modify all of memory. 10762 10763 Insns containing just `use' expressions directly precede the 10764`call_insn' insn to indicate which registers contain inputs to the 10765function. Similarly, if registers other than those in 10766`CALL_USED_REGISTERS' are clobbered by the called function, insns 10767containing a single `clobber' follow immediately after the call to 10768indicate which registers. 10769 10770 10771File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 10772 1077310.21 Structure Sharing Assumptions 10774=================================== 10775 10776The compiler assumes that certain kinds of RTL expressions are unique; 10777there do not exist two distinct objects representing the same value. 10778In other cases, it makes an opposite assumption: that no RTL expression 10779object of a certain kind appears in more than one place in the 10780containing structure. 10781 10782 These assumptions refer to a single function; except for the RTL 10783objects that describe global variables and external functions, and a 10784few standard objects such as small integer constants, no RTL objects 10785are common to two functions. 10786 10787 * Each pseudo-register has only a single `reg' object to represent 10788 it, and therefore only a single machine mode. 10789 10790 * For any symbolic label, there is only one `symbol_ref' object 10791 referring to it. 10792 10793 * All `const_int' expressions with equal values are shared. 10794 10795 * There is only one `pc' expression. 10796 10797 * There is only one `cc0' expression. 10798 10799 * There is only one `const_double' expression with value 0 for each 10800 floating point mode. Likewise for values 1 and 2. 10801 10802 * There is only one `const_vector' expression with value 0 for each 10803 vector mode, be it an integer or a double constant vector. 10804 10805 * No `label_ref' or `scratch' appears in more than one place in the 10806 RTL structure; in other words, it is safe to do a tree-walk of all 10807 the insns in the function and assume that each time a `label_ref' 10808 or `scratch' is seen it is distinct from all others that are seen. 10809 10810 * Only one `mem' object is normally created for each static variable 10811 or stack slot, so these objects are frequently shared in all the 10812 places they appear. However, separate but equal objects for these 10813 variables are occasionally made. 10814 10815 * When a single `asm' statement has multiple output operands, a 10816 distinct `asm_operands' expression is made for each output operand. 10817 However, these all share the vector which contains the sequence of 10818 input operands. This sharing is used later on to test whether two 10819 `asm_operands' expressions come from the same statement, so all 10820 optimizations must carefully preserve the sharing if they copy the 10821 vector at all. 10822 10823 * No RTL object appears in more than one place in the RTL structure 10824 except as described above. Many passes of the compiler rely on 10825 this by assuming that they can modify RTL objects in place without 10826 unwanted side-effects on other insns. 10827 10828 * During initial RTL generation, shared structure is freely 10829 introduced. After all the RTL for a function has been generated, 10830 all shared structure is copied by `unshare_all_rtl' in 10831 `emit-rtl.c', after which the above rules are guaranteed to be 10832 followed. 10833 10834 * During the combiner pass, shared structure within an insn can exist 10835 temporarily. However, the shared structure is copied before the 10836 combiner is finished with the insn. This is done by calling 10837 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'. 10838 10839 10840File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 10841 1084210.22 Reading RTL 10843================= 10844 10845To read an RTL object from a file, call `read_rtx'. It takes one 10846argument, a stdio stream, and returns a single RTL object. This routine 10847is defined in `read-rtl.c'. It is not available in the compiler 10848itself, only the various programs that generate the compiler back end 10849from the machine description. 10850 10851 People frequently have the idea of using RTL stored as text in a file 10852as an interface between a language front end and the bulk of GCC. This 10853idea is not feasible. 10854 10855 GCC was designed to use RTL internally only. Correct RTL for a given 10856program is very dependent on the particular target machine. And the RTL 10857does not contain all the information about the program. 10858 10859 The proper way to interface GCC to a new language front end is with 10860the "tree" data structure, described in the files `tree.h' and 10861`tree.def'. The documentation for this structure (*note GENERIC::) is 10862incomplete. 10863 10864 10865File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top 10866 1086711 GENERIC 10868********** 10869 10870The purpose of GENERIC is simply to provide a language-independent way 10871of representing an entire function in trees. To this end, it was 10872necessary to add a few new tree codes to the back end, but most 10873everything was already there. If you can express it with the codes in 10874`gcc/tree.def', it's GENERIC. 10875 10876 Early on, there was a great deal of debate about how to think about 10877statements in a tree IL. In GENERIC, a statement is defined as any 10878expression whose value, if any, is ignored. A statement will always 10879have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a 10880non-statement expression may also have side effects. A `CALL_EXPR', 10881for instance. 10882 10883 It would be possible for some local optimizations to work on the 10884GENERIC form of a function; indeed, the adapted tree inliner works fine 10885on GENERIC, but the current compiler performs inlining after lowering 10886to GIMPLE (a restricted form described in the next section). Indeed, 10887currently the frontends perform this lowering before handing off to 10888`tree_rest_of_compilation', but this seems inelegant. 10889 10890* Menu: 10891 10892* Deficiencies:: Topics net yet covered in this document. 10893* Tree overview:: All about `tree's. 10894* Types:: Fundamental and aggregate types. 10895* Declarations:: Type declarations and variables. 10896* Attributes:: Declaration and type attributes. 10897* Expressions: Expression trees. Operating on data. 10898* Statements:: Control flow and related trees. 10899* Functions:: Function bodies, linkage, and other aspects. 10900* Language-dependent trees:: Topics and trees specific to language front ends. 10901* C and C++ Trees:: Trees specific to C and C++. 10902* Java Trees:: Trees specific to Java. 10903 10904 10905File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 10906 1090711.1 Deficiencies 10908================= 10909 10910There are many places in which this document is incomplet and incorrekt. 10911It is, as of yet, only _preliminary_ documentation. 10912 10913 10914File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 10915 1091611.2 Overview 10917============= 10918 10919The central data structure used by the internal representation is the 10920`tree'. These nodes, while all of the C type `tree', are of many 10921varieties. A `tree' is a pointer type, but the object to which it 10922points may be of a variety of types. From this point forward, we will 10923refer to trees in ordinary type, rather than in `this font', except 10924when talking about the actual C type `tree'. 10925 10926 You can tell what kind of node a particular tree is by using the 10927`TREE_CODE' macro. Many, many macros take trees as input and return 10928trees as output. However, most macros require a certain kind of tree 10929node as input. In other words, there is a type-system for trees, but 10930it is not reflected in the C type-system. 10931 10932 For safety, it is useful to configure GCC with `--enable-checking'. 10933Although this results in a significant performance penalty (since all 10934tree types are checked at run-time), and is therefore inappropriate in a 10935release version, it is extremely helpful during the development process. 10936 10937 Many macros behave as predicates. Many, although not all, of these 10938predicates end in `_P'. Do not rely on the result type of these macros 10939being of any particular type. You may, however, rely on the fact that 10940the type can be compared to `0', so that statements like 10941 if (TEST_P (t) && !TEST_P (y)) 10942 x = 1; 10943 and 10944 int i = (TEST_P (t) != 0); 10945 are legal. Macros that return `int' values now may be changed to 10946return `tree' values, or other pointers in the future. Even those that 10947continue to return `int' may return multiple nonzero codes where 10948previously they returned only zero and one. Therefore, you should not 10949write code like 10950 if (TEST_P (t) == 1) 10951 as this code is not guaranteed to work correctly in the future. 10952 10953 You should not take the address of values returned by the macros or 10954functions described here. In particular, no guarantee is given that the 10955values are lvalues. 10956 10957 In general, the names of macros are all in uppercase, while the names 10958of functions are entirely in lowercase. There are rare exceptions to 10959this rule. You should assume that any macro or function whose name is 10960made up entirely of uppercase letters may evaluate its arguments more 10961than once. You may assume that a macro or function whose name is made 10962up entirely of lowercase letters will evaluate its arguments only once. 10963 10964 The `error_mark_node' is a special tree. Its tree code is 10965`ERROR_MARK', but since there is only ever one node with that code, the 10966usual practice is to compare the tree against `error_mark_node'. (This 10967test is just a test for pointer equality.) If an error has occurred 10968during front-end processing the flag `errorcount' will be set. If the 10969front end has encountered code it cannot handle, it will issue a 10970message to the user and set `sorrycount'. When these flags are set, 10971any macro or function which normally returns a tree of a particular 10972kind may instead return the `error_mark_node'. Thus, if you intend to 10973do any processing of erroneous code, you must be prepared to deal with 10974the `error_mark_node'. 10975 10976 Occasionally, a particular tree slot (like an operand to an expression, 10977or a particular field in a declaration) will be referred to as 10978"reserved for the back end". These slots are used to store RTL when 10979the tree is converted to RTL for use by the GCC back end. However, if 10980that process is not taking place (e.g., if the front end is being hooked 10981up to an intelligent editor), then those slots may be used by the back 10982end presently in use. 10983 10984 If you encounter situations that do not match this documentation, such 10985as tree nodes of types not mentioned here, or macros documented to 10986return entities of a particular kind that instead return entities of 10987some different kind, you have found a bug, either in the front end or in 10988the documentation. Please report these bugs as you would any other bug. 10989 10990* Menu: 10991 10992* Macros and Functions::Macros and functions that can be used with all trees. 10993* Identifiers:: The names of things. 10994* Containers:: Lists and vectors. 10995 10996 10997File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 10998 1099911.2.1 Trees 11000------------ 11001 11002All GENERIC trees have two fields in common. First, `TREE_CHAIN' is a 11003pointer that can be used as a singly-linked list to other trees. The 11004other is `TREE_TYPE'. Many trees store the type of an expression or 11005declaration in this field. 11006 11007 These are some other functions for handling trees: 11008 11009`tree_size' 11010 Return the number of bytes a tree takes. 11011 11012`build0' 11013`build1' 11014`build2' 11015`build3' 11016`build4' 11017`build5' 11018`build6' 11019 These functions build a tree and supply values to put in each 11020 parameter. The basic signature is `code, type, [operands]'. 11021 `code' is the `TREE_CODE', and `type' is a tree representing the 11022 `TREE_TYPE'. These are followed by the operands, each of which is 11023 also a tree. 11024 11025 11026 11027File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 11028 1102911.2.2 Identifiers 11030------------------ 11031 11032An `IDENTIFIER_NODE' represents a slightly more general concept that 11033the standard C or C++ concept of identifier. In particular, an 11034`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters. 11035 11036 There are never two distinct `IDENTIFIER_NODE's representing the same 11037identifier. Therefore, you may use pointer equality to compare 11038`IDENTIFIER_NODE's, rather than using a routine like `strcmp'. Use 11039`get_identifier' to obtain the unique `IDENTIFIER_NODE' for a supplied 11040string. 11041 11042 You can use the following macros to access identifiers: 11043`IDENTIFIER_POINTER' 11044 The string represented by the identifier, represented as a 11045 `char*'. This string is always `NUL'-terminated, and contains no 11046 embedded `NUL' characters. 11047 11048`IDENTIFIER_LENGTH' 11049 The length of the string returned by `IDENTIFIER_POINTER', not 11050 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH 11051 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'. 11052 11053`IDENTIFIER_OPNAME_P' 11054 This predicate holds if the identifier represents the name of an 11055 overloaded operator. In this case, you should not depend on the 11056 contents of either the `IDENTIFIER_POINTER' or the 11057 `IDENTIFIER_LENGTH'. 11058 11059`IDENTIFIER_TYPENAME_P' 11060 This predicate holds if the identifier represents the name of a 11061 user-defined conversion operator. In this case, the `TREE_TYPE' of 11062 the `IDENTIFIER_NODE' holds the type to which the conversion 11063 operator converts. 11064 11065 11066 11067File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 11068 1106911.2.3 Containers 11070----------------- 11071 11072Two common container data structures can be represented directly with 11073tree nodes. A `TREE_LIST' is a singly linked list containing two trees 11074per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node. 11075(Often, the `TREE_PURPOSE' contains some kind of tag, or additional 11076information, while the `TREE_VALUE' contains the majority of the 11077payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE', 11078while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of 11079equal stature.) Given one `TREE_LIST' node, the next node is found by 11080following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then 11081you have reached the end of the list. 11082 11083 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer 11084(not a tree) giving the number of nodes in the vector. The nodes 11085themselves are accessed using the `TREE_VEC_ELT' macro, which takes two 11086arguments. The first is the `TREE_VEC' in question; the second is an 11087integer indicating which element in the vector is desired. The 11088elements are indexed from zero. 11089 11090 11091File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 11092 1109311.3 Types 11094========== 11095 11096All types have corresponding tree nodes. However, you should not assume 11097that there is exactly one tree node corresponding to each type. There 11098are often multiple nodes corresponding to the same type. 11099 11100 For the most part, different kinds of types have different tree codes. 11101(For example, pointer types use a `POINTER_TYPE' code while arrays use 11102an `ARRAY_TYPE' code.) However, pointers to member functions use the 11103`RECORD_TYPE' code. Therefore, when writing a `switch' statement that 11104depends on the code associated with a particular type, you should take 11105care to handle pointers to member functions under the `RECORD_TYPE' 11106case label. 11107 11108 The following functions and macros deal with cv-qualification of types: 11109`TYPE_MAIN_VARIANT' 11110 This macro returns the unqualified version of a type. It may be 11111 applied to an unqualified type, but it is not always the identity 11112 function in that case. 11113 11114 A few other macros and functions are usable with all types: 11115`TYPE_SIZE' 11116 The number of bits required to represent the type, represented as 11117 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 11118 `NULL_TREE'. 11119 11120`TYPE_ALIGN' 11121 The alignment of the type, in bits, represented as an `int'. 11122 11123`TYPE_NAME' 11124 This macro returns a declaration (in the form of a `TYPE_DECL') for 11125 the type. (Note this macro does _not_ return an 11126 `IDENTIFIER_NODE', as you might expect, given its name!) You can 11127 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 11128 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 11129 that is not a built-in type, the result of a typedef, or a named 11130 class type. 11131 11132`TYPE_CANONICAL' 11133 This macro returns the "canonical" type for the given type node. 11134 Canonical types are used to improve performance in the C++ and 11135 Objective-C++ front ends by allowing efficient comparison between 11136 two type nodes in `same_type_p': if the `TYPE_CANONICAL' values of 11137 the types are equal, the types are equivalent; otherwise, the types 11138 are not equivalent. The notion of equivalence for canonical types 11139 is the same as the notion of type equivalence in the language 11140 itself. For instance, 11141 11142 When `TYPE_CANONICAL' is `NULL_TREE', there is no canonical type 11143 for the given type node. In this case, comparison between this 11144 type and any other type requires the compiler to perform a deep, 11145 "structural" comparison to see if the two type nodes have the same 11146 form and properties. 11147 11148 The canonical type for a node is always the most fundamental type 11149 in the equivalence class of types. For instance, `int' is its own 11150 canonical type. A typedef `I' of `int' will have `int' as its 11151 canonical type. Similarly, `I*' and a typedef `IP' (defined to 11152 `I*') will has `int*' as their canonical type. When building a new 11153 type node, be sure to set `TYPE_CANONICAL' to the appropriate 11154 canonical type. If the new type is a compound type (built from 11155 other types), and any of those other types require structural 11156 equality, use `SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the 11157 new type also requires structural equality. Finally, if for some 11158 reason you cannot guarantee that `TYPE_CANONICAL' will point to 11159 the canonical type, use `SET_TYPE_STRUCTURAL_EQUALITY' to make 11160 sure that the new type-and any type constructed based on 11161 it-requires structural equality. If you suspect that the canonical 11162 type system is miscomparing types, pass `--param 11163 verify-canonical-types=1' to the compiler or configure with 11164 `--enable-checking' to force the compiler to verify its 11165 canonical-type comparisons against the structural comparisons; the 11166 compiler will then print any warnings if the canonical types 11167 miscompare. 11168 11169`TYPE_STRUCTURAL_EQUALITY_P' 11170 This predicate holds when the node requires structural equality 11171 checks, e.g., when `TYPE_CANONICAL' is `NULL_TREE'. 11172 11173`SET_TYPE_STRUCTURAL_EQUALITY' 11174 This macro states that the type node it is given requires 11175 structural equality checks, e.g., it sets `TYPE_CANONICAL' to 11176 `NULL_TREE'. 11177 11178`same_type_p' 11179 This predicate takes two types as input, and holds if they are the 11180 same type. For example, if one type is a `typedef' for the other, 11181 or both are `typedef's for the same type. This predicate also 11182 holds if the two trees given as input are simply copies of one 11183 another; i.e., there is no difference between them at the source 11184 level, but, for whatever reason, a duplicate has been made in the 11185 representation. You should never use `==' (pointer equality) to 11186 compare types; always use `same_type_p' instead. 11187 11188 Detailed below are the various kinds of types, and the macros that can 11189be used to access them. Although other kinds of types are used 11190elsewhere in G++, the types described here are the only ones that you 11191will encounter while examining the intermediate representation. 11192 11193`VOID_TYPE' 11194 Used to represent the `void' type. 11195 11196`INTEGER_TYPE' 11197 Used to represent the various integral types, including `char', 11198 `short', `int', `long', and `long long'. This code is not used 11199 for enumeration types, nor for the `bool' type. The 11200 `TYPE_PRECISION' is the number of bits used in the representation, 11201 represented as an `unsigned int'. (Note that in the general case 11202 this is not the same value as `TYPE_SIZE'; suppose that there were 11203 a 24-bit integer type, but that alignment requirements for the ABI 11204 required 32-bit alignment. Then, `TYPE_SIZE' would be an 11205 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The 11206 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it 11207 is signed. 11208 11209 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer 11210 that may be represented by this type. Similarly, the 11211 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that 11212 may be represented by this type. 11213 11214`REAL_TYPE' 11215 Used to represent the `float', `double', and `long double' types. 11216 The number of bits in the floating-point representation is given 11217 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case. 11218 11219`FIXED_POINT_TYPE' 11220 Used to represent the `short _Fract', `_Fract', `long _Fract', 11221 `long long _Fract', `short _Accum', `_Accum', `long _Accum', and 11222 `long long _Accum' types. The number of bits in the fixed-point 11223 representation is given by `TYPE_PRECISION', as in the 11224 `INTEGER_TYPE' case. There may be padding bits, fractional bits 11225 and integral bits. The number of fractional bits is given by 11226 `TYPE_FBIT', and the number of integral bits is given by 11227 `TYPE_IBIT'. The fixed-point type is unsigned if `TYPE_UNSIGNED' 11228 holds; otherwise, it is signed. The fixed-point type is 11229 saturating if `TYPE_SATURATING' holds; otherwise, it is not 11230 saturating. 11231 11232`COMPLEX_TYPE' 11233 Used to represent GCC built-in `__complex__' data types. The 11234 `TREE_TYPE' is the type of the real and imaginary parts. 11235 11236`ENUMERAL_TYPE' 11237 Used to represent an enumeration type. The `TYPE_PRECISION' gives 11238 (as an `int'), the number of bits used to represent the type. If 11239 there are no negative enumeration constants, `TYPE_UNSIGNED' will 11240 hold. The minimum and maximum enumeration constants may be 11241 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively; 11242 each of these macros returns an `INTEGER_CST'. 11243 11244 The actual enumeration constants themselves may be obtained by 11245 looking at the `TYPE_VALUES'. This macro will return a 11246 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each 11247 node will be an `IDENTIFIER_NODE' giving the name of the constant; 11248 the `TREE_VALUE' will be an `INTEGER_CST' giving the value 11249 assigned to that constant. These constants will appear in the 11250 order in which they were declared. The `TREE_TYPE' of each of 11251 these constants will be the type of enumeration type itself. 11252 11253`BOOLEAN_TYPE' 11254 Used to represent the `bool' type. 11255 11256`POINTER_TYPE' 11257 Used to represent pointer types, and pointer to data member types. 11258 The `TREE_TYPE' gives the type to which this type points. 11259 11260`REFERENCE_TYPE' 11261 Used to represent reference types. The `TREE_TYPE' gives the type 11262 to which this type refers. 11263 11264`FUNCTION_TYPE' 11265 Used to represent the type of non-member functions and of static 11266 member functions. The `TREE_TYPE' gives the return type of the 11267 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument 11268 types. The `TREE_VALUE' of each node in this list is the type of 11269 the corresponding argument; the `TREE_PURPOSE' is an expression 11270 for the default argument value, if any. If the last node in the 11271 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is 11272 the `void_type_node'), then functions of this type do not take 11273 variable arguments. Otherwise, they do take a variable number of 11274 arguments. 11275 11276 Note that in C (but not in C++) a function declared like `void f()' 11277 is an unprototyped function taking a variable number of arguments; 11278 the `TYPE_ARG_TYPES' of such a function will be `NULL'. 11279 11280`METHOD_TYPE' 11281 Used to represent the type of a non-static member function. Like a 11282 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The 11283 type of `*this', i.e., the class of which functions of this type 11284 are a member, is given by the `TYPE_METHOD_BASETYPE'. The 11285 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE', 11286 and includes the `this' argument. 11287 11288`ARRAY_TYPE' 11289 Used to represent array types. The `TREE_TYPE' gives the type of 11290 the elements in the array. If the array-bound is present in the 11291 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose 11292 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper 11293 bounds of the array, respectively. The `TYPE_MIN_VALUE' will 11294 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE' 11295 will be one less than the number of elements in the array, i.e., 11296 the highest value which may be used to index an element in the 11297 array. 11298 11299`RECORD_TYPE' 11300 Used to represent `struct' and `class' types, as well as pointers 11301 to member functions and similar constructs in other languages. 11302 `TYPE_FIELDS' contains the items contained in this type, each of 11303 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or 11304 `TYPE_DECL'. You may not make any assumptions about the ordering 11305 of the fields in the type or whether one or more of them overlap. 11306 11307`UNION_TYPE' 11308 Used to represent `union' types. Similar to `RECORD_TYPE' except 11309 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position 11310 zero. 11311 11312`QUAL_UNION_TYPE' 11313 Used to represent part of a variant record in Ada. Similar to 11314 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER' 11315 field, which contains a boolean expression that indicates whether 11316 the field is present in the object. The type will only have one 11317 field, so each field's `DECL_QUALIFIER' is only evaluated if none 11318 of the expressions in the previous fields in `TYPE_FIELDS' are 11319 nonzero. Normally these expressions will reference a field in the 11320 outer object using a `PLACEHOLDER_EXPR'. 11321 11322`LANG_TYPE' 11323 This node is used to represent a language-specific type. The front 11324 end must handle it. 11325 11326`OFFSET_TYPE' 11327 This node is used to represent a pointer-to-data member. For a 11328 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the 11329 `TREE_TYPE' is the type of `m'. 11330 11331 11332 There are variables whose values represent some of the basic types. 11333These include: 11334`void_type_node' 11335 A node for `void'. 11336 11337`integer_type_node' 11338 A node for `int'. 11339 11340`unsigned_type_node.' 11341 A node for `unsigned int'. 11342 11343`char_type_node.' 11344 A node for `char'. 11345 It may sometimes be useful to compare one of these variables with a 11346type in hand, using `same_type_p'. 11347 11348 11349File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 11350 1135111.4 Declarations 11352================= 11353 11354This section covers the various kinds of declarations that appear in the 11355internal representation, except for declarations of functions 11356(represented by `FUNCTION_DECL' nodes), which are described in *note 11357Functions::. 11358 11359* Menu: 11360 11361* Working with declarations:: Macros and functions that work on 11362declarations. 11363* Internal structure:: How declaration nodes are represented. 11364 11365 11366File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 11367 1136811.4.1 Working with declarations 11369-------------------------------- 11370 11371Some macros can be used with any kind of declaration. These include: 11372`DECL_NAME' 11373 This macro returns an `IDENTIFIER_NODE' giving the name of the 11374 entity. 11375 11376`TREE_TYPE' 11377 This macro returns the type of the entity declared. 11378 11379`EXPR_FILENAME' 11380 This macro returns the name of the file in which the entity was 11381 declared, as a `char*'. For an entity declared implicitly by the 11382 compiler (like `__builtin_memcpy'), this will be the string 11383 `"<internal>"'. 11384 11385`EXPR_LINENO' 11386 This macro returns the line number at which the entity was 11387 declared, as an `int'. 11388 11389`DECL_ARTIFICIAL' 11390 This predicate holds if the declaration was implicitly generated 11391 by the compiler. For example, this predicate will hold of an 11392 implicitly declared member function, or of the `TYPE_DECL' 11393 implicitly generated for a class type. Recall that in C++ code 11394 like: 11395 struct S {}; 11396 is roughly equivalent to C code like: 11397 struct S {}; 11398 typedef struct S S; 11399 The implicitly generated `typedef' declaration is represented by a 11400 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds. 11401 11402 11403 The various kinds of declarations include: 11404`LABEL_DECL' 11405 These nodes are used to represent labels in function bodies. For 11406 more information, see *note Functions::. These nodes only appear 11407 in block scopes. 11408 11409`CONST_DECL' 11410 These nodes are used to represent enumeration constants. The 11411 value of the constant is given by `DECL_INITIAL' which will be an 11412 `INTEGER_CST' with the same type as the `TREE_TYPE' of the 11413 `CONST_DECL', i.e., an `ENUMERAL_TYPE'. 11414 11415`RESULT_DECL' 11416 These nodes represent the value returned by a function. When a 11417 value is assigned to a `RESULT_DECL', that indicates that the 11418 value should be returned, via bitwise copy, by the function. You 11419 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as 11420 with a `VAR_DECL'. 11421 11422`TYPE_DECL' 11423 These nodes represent `typedef' declarations. The `TREE_TYPE' is 11424 the type declared to have the name given by `DECL_NAME'. In some 11425 cases, there is no associated name. 11426 11427`VAR_DECL' 11428 These nodes represent variables with namespace or block scope, as 11429 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are 11430 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you 11431 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the 11432 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since 11433 special attributes may have been applied to the variable to give 11434 it a particular size and alignment. You may use the predicates 11435 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the 11436 storage class specifiers `static' or `extern' were used to declare 11437 a variable. 11438 11439 If this variable is initialized (but does not require a 11440 constructor), the `DECL_INITIAL' will be an expression for the 11441 initializer. The initializer should be evaluated, and a bitwise 11442 copy into the variable performed. If the `DECL_INITIAL' is the 11443 `error_mark_node', there is an initializer, but it is given by an 11444 explicit statement later in the code; no bitwise copy is required. 11445 11446 GCC provides an extension that allows either automatic variables, 11447 or global variables, to be placed in particular registers. This 11448 extension is being used for a particular `VAR_DECL' if 11449 `DECL_REGISTER' holds for the `VAR_DECL', and if 11450 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case, 11451 `DECL_ASSEMBLER_NAME' is the name of the register into which the 11452 variable will be placed. 11453 11454`PARM_DECL' 11455 Used to represent a parameter to a function. Treat these nodes 11456 similarly to `VAR_DECL' nodes. These nodes only appear in the 11457 `DECL_ARGUMENTS' for a `FUNCTION_DECL'. 11458 11459 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will 11460 actually be used when a value is passed to this function. It may 11461 be a wider type than the `TREE_TYPE' of the parameter; for 11462 example, the ordinary type might be `short' while the 11463 `DECL_ARG_TYPE' is `int'. 11464 11465`DEBUG_EXPR_DECL' 11466 Used to represent an anonymous debug-information temporary created 11467 to hold an expression as it is optimized away, so that its value 11468 can be referenced in debug bind statements. 11469 11470`FIELD_DECL' 11471 These nodes represent non-static data members. The `DECL_SIZE' and 11472 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the 11473 field within the parent record is specified by a combination of 11474 three attributes. `DECL_FIELD_OFFSET' is the position, counting 11475 in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the 11476 bit of the field closest to the beginning of the structure. 11477 `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 11478 field within this word; this may be nonzero even for fields that 11479 are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than 11480 the natural alignment of the field's type. 11481 11482 If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 11483 bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was 11484 originally specified for it, while DECL_TYPE may be a modified 11485 type with lesser precision, according to the size of the bit field. 11486 11487`NAMESPACE_DECL' 11488 Namespaces provide a name hierarchy for other declarations. They 11489 appear in the `DECL_CONTEXT' of other `_DECL' nodes. 11490 11491 11492 11493File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 11494 1149511.4.2 Internal structure 11496------------------------- 11497 11498`DECL' nodes are represented internally as a hierarchy of structures. 11499 11500* Menu: 11501 11502* Current structure hierarchy:: The current DECL node structure 11503hierarchy. 11504* Adding new DECL node types:: How to add a new DECL node to a 11505frontend. 11506 11507 11508File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 11509 1151011.4.2.1 Current structure hierarchy 11511.................................... 11512 11513`struct tree_decl_minimal' 11514 This is the minimal structure to inherit from in order for common 11515 `DECL' macros to work. The fields it contains are a unique ID, 11516 source location, context, and name. 11517 11518`struct tree_decl_common' 11519 This structure inherits from `struct tree_decl_minimal'. It 11520 contains fields that most `DECL' nodes need, such as a field to 11521 store alignment, machine mode, size, and attributes. 11522 11523`struct tree_field_decl' 11524 This structure inherits from `struct tree_decl_common'. It is 11525 used to represent `FIELD_DECL'. 11526 11527`struct tree_label_decl' 11528 This structure inherits from `struct tree_decl_common'. It is 11529 used to represent `LABEL_DECL'. 11530 11531`struct tree_translation_unit_decl' 11532 This structure inherits from `struct tree_decl_common'. It is 11533 used to represent `TRANSLATION_UNIT_DECL'. 11534 11535`struct tree_decl_with_rtl' 11536 This structure inherits from `struct tree_decl_common'. It 11537 contains a field to store the low-level RTL associated with a 11538 `DECL' node. 11539 11540`struct tree_result_decl' 11541 This structure inherits from `struct tree_decl_with_rtl'. It is 11542 used to represent `RESULT_DECL'. 11543 11544`struct tree_const_decl' 11545 This structure inherits from `struct tree_decl_with_rtl'. It is 11546 used to represent `CONST_DECL'. 11547 11548`struct tree_parm_decl' 11549 This structure inherits from `struct tree_decl_with_rtl'. It is 11550 used to represent `PARM_DECL'. 11551 11552`struct tree_decl_with_vis' 11553 This structure inherits from `struct tree_decl_with_rtl'. It 11554 contains fields necessary to store visibility information, as well 11555 as a section name and assembler name. 11556 11557`struct tree_var_decl' 11558 This structure inherits from `struct tree_decl_with_vis'. It is 11559 used to represent `VAR_DECL'. 11560 11561`struct tree_function_decl' 11562 This structure inherits from `struct tree_decl_with_vis'. It is 11563 used to represent `FUNCTION_DECL'. 11564 11565 11566 11567File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 11568 1156911.4.2.2 Adding new DECL node types 11570................................... 11571 11572Adding a new `DECL' tree consists of the following steps 11573 11574Add a new tree code for the `DECL' node 11575 For language specific `DECL' nodes, there is a `.def' file in each 11576 frontend directory where the tree code should be added. For 11577 `DECL' nodes that are part of the middle-end, the code should be 11578 added to `tree.def'. 11579 11580Create a new structure type for the `DECL' node 11581 These structures should inherit from one of the existing 11582 structures in the language hierarchy by using that structure as 11583 the first member. 11584 11585 struct tree_foo_decl 11586 { 11587 struct tree_decl_with_vis common; 11588 } 11589 11590 Would create a structure name `tree_foo_decl' that inherits from 11591 `struct tree_decl_with_vis'. 11592 11593 For language specific `DECL' nodes, this new structure type should 11594 go in the appropriate `.h' file. For `DECL' nodes that are part 11595 of the middle-end, the structure type should go in `tree.h'. 11596 11597Add a member to the tree structure enumerator for the node 11598 For garbage collection and dynamic checking purposes, each `DECL' 11599 node structure type is required to have a unique enumerator value 11600 specified with it. For language specific `DECL' nodes, this new 11601 enumerator value should go in the appropriate `.def' file. For 11602 `DECL' nodes that are part of the middle-end, the enumerator 11603 values are specified in `treestruct.def'. 11604 11605Update `union tree_node' 11606 In order to make your new structure type usable, it must be added 11607 to `union tree_node'. For language specific `DECL' nodes, a new 11608 entry should be added to the appropriate `.h' file of the form 11609 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 11610 For `DECL' nodes that are part of the middle-end, the additional 11611 member goes directly into `union tree_node' in `tree.h'. 11612 11613Update dynamic checking info 11614 In order to be able to check whether accessing a named portion of 11615 `union tree_node' is legal, and whether a certain `DECL' node 11616 contains one of the enumerated `DECL' node structures in the 11617 hierarchy, a simple lookup table is used. This lookup table needs 11618 to be kept up to date with the tree structure hierarchy, or else 11619 checking and containment macros will fail inappropriately. 11620 11621 For language specific `DECL' nodes, their is an `init_ts' function 11622 in an appropriate `.c' file, which initializes the lookup table. 11623 Code setting up the table for new `DECL' nodes should be added 11624 there. For each `DECL' tree code and enumerator value 11625 representing a member of the inheritance hierarchy, the table 11626 should contain 1 if that tree code inherits (directly or 11627 indirectly) from that member. Thus, a `FOO_DECL' node derived 11628 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL', 11629 would be set up as follows 11630 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 11631 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 11632 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 11633 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 11634 11635 For `DECL' nodes that are part of the middle-end, the setup code 11636 goes into `tree.c'. 11637 11638Add macros to access any new fields and flags 11639 Each added field or flag should have a macro that is used to access 11640 it, that performs appropriate checking to ensure only the right 11641 type of `DECL' nodes access the field. 11642 11643 These macros generally take the following form 11644 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 11645 However, if the structure is simply a base class for further 11646 structures, something like the following should be used 11647 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 11648 #define BASE_STRUCT_FIELDNAME(NODE) \ 11649 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 11650 11651 11652 11653File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 11654 1165511.5 Attributes in trees 11656======================== 11657 11658Attributes, as specified using the `__attribute__' keyword, are 11659represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the 11660name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a 11661`TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' 11662if there are no arguments; the arguments are stored as the `TREE_VALUE' 11663of successive entries in the list, and may be identifiers or 11664expressions. The `TREE_CHAIN' of the attribute is the next attribute 11665in a list of attributes applying to the same declaration or type, or 11666`NULL_TREE' if there are no further attributes in the list. 11667 11668 Attributes may be attached to declarations and to types; these 11669attributes may be accessed with the following macros. All attributes 11670are stored in this way, and many also cause other changes to the 11671declaration or type or to other internal compiler data structures. 11672 11673 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 11674 This macro returns the attributes on the declaration DECL. 11675 11676 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 11677 This macro returns the attributes on the type TYPE. 11678 11679 11680File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 11681 1168211.6 Expressions 11683================ 11684 11685The internal representation for expressions is for the most part quite 11686straightforward. However, there are a few facts that one must bear in 11687mind. In particular, the expression "tree" is actually a directed 11688acyclic graph. (For example there may be many references to the integer 11689constant zero throughout the source program; many of these will be 11690represented by the same expression node.) You should not rely on 11691certain kinds of node being shared, nor should you rely on certain 11692kinds of nodes being unshared. 11693 11694 The following macros can be used with all expression nodes: 11695 11696`TREE_TYPE' 11697 Returns the type of the expression. This value may not be 11698 precisely the same type that would be given the expression in the 11699 original program. 11700 11701 In what follows, some nodes that one might expect to always have type 11702`bool' are documented to have either integral or boolean type. At some 11703point in the future, the C front end may also make use of this same 11704intermediate representation, and at this point these nodes will 11705certainly have integral type. The previous sentence is not meant to 11706imply that the C++ front end does not or will not give these nodes 11707integral type. 11708 11709 Below, we list the various kinds of expression nodes. Except where 11710noted otherwise, the operands to an expression are accessed using the 11711`TREE_OPERAND' macro. For example, to access the first operand to a 11712binary plus expression `expr', use: 11713 11714 TREE_OPERAND (expr, 0) 11715 As this example indicates, the operands are zero-indexed. 11716 11717* Menu: 11718 11719* Constants: Constant expressions. 11720* Storage References:: 11721* Unary and Binary Expressions:: 11722* Vectors:: 11723 11724 11725File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 11726 1172711.6.1 Constant expressions 11728--------------------------- 11729 11730The table below begins with constants, moves on to unary expressions, 11731then proceeds to binary expressions, and concludes with various other 11732kinds of expressions: 11733 11734`INTEGER_CST' 11735 These nodes represent integer constants. Note that the type of 11736 these constants is obtained with `TREE_TYPE'; they are not always 11737 of type `int'. In particular, `char' constants are represented 11738 with `INTEGER_CST' nodes. The value of the integer constant `e' is 11739 given by 11740 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT) 11741 + TREE_INST_CST_LOW (e)) 11742 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. 11743 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a 11744 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as 11745 a signed or unsigned quantity depending on the type of the 11746 constant. In general, the expression given above will overflow, 11747 so it should not be used to calculate the value of the constant. 11748 11749 The variable `integer_zero_node' is an integer constant with value 11750 zero. Similarly, `integer_one_node' is an integer constant with 11751 value one. The `size_zero_node' and `size_one_node' variables are 11752 analogous, but have type `size_t' rather than `int'. 11753 11754 The function `tree_int_cst_lt' is a predicate which holds if its 11755 first argument is less than its second. Both constants are 11756 assumed to have the same signedness (i.e., either both should be 11757 signed or both should be unsigned.) The full width of the 11758 constant is used when doing the comparison; the usual rules about 11759 promotions and conversions are ignored. Similarly, 11760 `tree_int_cst_equal' holds if the two constants are equal. The 11761 `tree_int_cst_sgn' function returns the sign of a constant. The 11762 value is `1', `0', or `-1' according on whether the constant is 11763 greater than, equal to, or less than zero. Again, the signedness 11764 of the constant's type is taken into account; an unsigned constant 11765 is never less than zero, no matter what its bit-pattern. 11766 11767`REAL_CST' 11768 FIXME: Talk about how to obtain representations of this constant, 11769 do comparisons, and so forth. 11770 11771`FIXED_CST' 11772 These nodes represent fixed-point constants. The type of these 11773 constants is obtained with `TREE_TYPE'. `TREE_FIXED_CST_PTR' 11774 points to a `struct fixed_value'; `TREE_FIXED_CST' returns the 11775 structure itself. `struct fixed_value' contains `data' with the 11776 size of two `HOST_BITS_PER_WIDE_INT' and `mode' as the associated 11777 fixed-point machine mode for `data'. 11778 11779`COMPLEX_CST' 11780 These nodes are used to represent complex number constants, that 11781 is a `__complex__' whose parts are constant nodes. The 11782 `TREE_REALPART' and `TREE_IMAGPART' return the real and the 11783 imaginary parts respectively. 11784 11785`VECTOR_CST' 11786 These nodes are used to represent vector constants, whose parts are 11787 constant nodes. Each individual constant node is either an 11788 integer or a double constant node. The first operand is a 11789 `TREE_LIST' of the constant nodes and is accessed through 11790 `TREE_VECTOR_CST_ELTS'. 11791 11792`STRING_CST' 11793 These nodes represent string-constants. The `TREE_STRING_LENGTH' 11794 returns the length of the string, as an `int'. The 11795 `TREE_STRING_POINTER' is a `char*' containing the string itself. 11796 The string may not be `NUL'-terminated, and it may contain 11797 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' 11798 includes the trailing `NUL' if it is present. 11799 11800 For wide string constants, the `TREE_STRING_LENGTH' is the number 11801 of bytes in the string, and the `TREE_STRING_POINTER' points to an 11802 array of the bytes of the string, as represented on the target 11803 system (that is, as integers in the target endianness). Wide and 11804 non-wide string constants are distinguished only by the `TREE_TYPE' 11805 of the `STRING_CST'. 11806 11807 FIXME: The formats of string constants are not well-defined when 11808 the target system bytes are not the same width as host system 11809 bytes. 11810 11811 11812 11813File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 11814 1181511.6.2 References to storage 11816---------------------------- 11817 11818`ARRAY_REF' 11819 These nodes represent array accesses. The first operand is the 11820 array; the second is the index. To calculate the address of the 11821 memory accessed, you must scale the index by the size of the type 11822 of the array elements. The type of these expressions must be the 11823 type of a component of the array. The third and fourth operands 11824 are used after gimplification to represent the lower bound and 11825 component size but should not be used directly; call 11826 `array_ref_low_bound' and `array_ref_element_size' instead. 11827 11828`ARRAY_RANGE_REF' 11829 These nodes represent access to a range (or "slice") of an array. 11830 The operands are the same as that for `ARRAY_REF' and have the same 11831 meanings. The type of these expressions must be an array whose 11832 component type is the same as that of the first operand. The 11833 range of that array type determines the amount of data these 11834 expressions access. 11835 11836`TARGET_MEM_REF' 11837 These nodes represent memory accesses whose address directly map to 11838 an addressing mode of the target architecture. The first argument 11839 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed 11840 address. The second argument is `TMR_BASE' and the third one is 11841 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an 11842 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an 11843 `INTEGER_CST'. Any of the arguments may be NULL if the 11844 appropriate component does not appear in the address. Address of 11845 the `TARGET_MEM_REF' is determined in the following way. 11846 11847 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 11848 11849 The sixth argument is the reference to the original memory access, 11850 which is preserved for the purposes of the RTL alias analysis. 11851 The seventh argument is a tag representing the results of tree 11852 level alias analysis. 11853 11854`ADDR_EXPR' 11855 These nodes are used to represent the address of an object. (These 11856 expressions will always have pointer or reference type.) The 11857 operand may be another expression, or it may be a declaration. 11858 11859 As an extension, GCC allows users to take the address of a label. 11860 In this case, the operand of the `ADDR_EXPR' will be a 11861 `LABEL_DECL'. The type of such an expression is `void*'. 11862 11863 If the object addressed is not an lvalue, a temporary is created, 11864 and the address of the temporary is used. 11865 11866`INDIRECT_REF' 11867 These nodes are used to represent the object pointed to by a 11868 pointer. The operand is the pointer being dereferenced; it will 11869 always have pointer or reference type. 11870 11871`MEM_REF' 11872 These nodes are used to represent the object pointed to by a 11873 pointer offset by a constant. The first operand is the pointer 11874 being dereferenced; it will always have pointer or reference type. 11875 The second operand is a pointer constant. Its type is specifying 11876 the type to be used for type-based alias analysis. 11877 11878`COMPONENT_REF' 11879 These nodes represent non-static data member accesses. The first 11880 operand is the object (rather than a pointer to it); the second 11881 operand is the `FIELD_DECL' for the data member. The third 11882 operand represents the byte offset of the field, but should not be 11883 used directly; call `component_ref_field_offset' instead. 11884 11885 11886 11887File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 11888 1188911.6.3 Unary and Binary Expressions 11890----------------------------------- 11891 11892`NEGATE_EXPR' 11893 These nodes represent unary negation of the single operand, for 11894 both integer and floating-point types. The type of negation can be 11895 determined by looking at the type of the expression. 11896 11897 The behavior of this operation on signed arithmetic overflow is 11898 controlled by the `flag_wrapv' and `flag_trapv' variables. 11899 11900`ABS_EXPR' 11901 These nodes represent the absolute value of the single operand, for 11902 both integer and floating-point types. This is typically used to 11903 implement the `abs', `labs' and `llabs' builtins for integer 11904 types, and the `fabs', `fabsf' and `fabsl' builtins for floating 11905 point types. The type of abs operation can be determined by 11906 looking at the type of the expression. 11907 11908 This node is not used for complex types. To represent the modulus 11909 or complex abs of a complex value, use the `BUILT_IN_CABS', 11910 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to 11911 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions. 11912 11913`BIT_NOT_EXPR' 11914 These nodes represent bitwise complement, and will always have 11915 integral type. The only operand is the value to be complemented. 11916 11917`TRUTH_NOT_EXPR' 11918 These nodes represent logical negation, and will always have 11919 integral (or boolean) type. The operand is the value being 11920 negated. The type of the operand and that of the result are 11921 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 11922 11923`PREDECREMENT_EXPR' 11924`PREINCREMENT_EXPR' 11925`POSTDECREMENT_EXPR' 11926`POSTINCREMENT_EXPR' 11927 These nodes represent increment and decrement expressions. The 11928 value of the single operand is computed, and the operand 11929 incremented or decremented. In the case of `PREDECREMENT_EXPR' and 11930 `PREINCREMENT_EXPR', the value of the expression is the value 11931 resulting after the increment or decrement; in the case of 11932 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before 11933 the increment or decrement occurs. The type of the operand, like 11934 that of the result, will be either integral, boolean, or 11935 floating-point. 11936 11937`FIX_TRUNC_EXPR' 11938 These nodes represent conversion of a floating-point value to an 11939 integer. The single operand will have a floating-point type, while 11940 the complete expression will have an integral (or boolean) type. 11941 The operand is rounded towards zero. 11942 11943`FLOAT_EXPR' 11944 These nodes represent conversion of an integral (or boolean) value 11945 to a floating-point value. The single operand will have integral 11946 type, while the complete expression will have a floating-point 11947 type. 11948 11949 FIXME: How is the operand supposed to be rounded? Is this 11950 dependent on `-mieee'? 11951 11952`COMPLEX_EXPR' 11953 These nodes are used to represent complex numbers constructed from 11954 two expressions of the same (integer or real) type. The first 11955 operand is the real part and the second operand is the imaginary 11956 part. 11957 11958`CONJ_EXPR' 11959 These nodes represent the conjugate of their operand. 11960 11961`REALPART_EXPR' 11962`IMAGPART_EXPR' 11963 These nodes represent respectively the real and the imaginary parts 11964 of complex numbers (their sole argument). 11965 11966`NON_LVALUE_EXPR' 11967 These nodes indicate that their one and only operand is not an 11968 lvalue. A back end can treat these identically to the single 11969 operand. 11970 11971`NOP_EXPR' 11972 These nodes are used to represent conversions that do not require 11973 any code-generation. For example, conversion of a `char*' to an 11974 `int*' does not require any code be generated; such a conversion is 11975 represented by a `NOP_EXPR'. The single operand is the expression 11976 to be converted. The conversion from a pointer to a reference is 11977 also represented with a `NOP_EXPR'. 11978 11979`CONVERT_EXPR' 11980 These nodes are similar to `NOP_EXPR's, but are used in those 11981 situations where code may need to be generated. For example, if an 11982 `int*' is converted to an `int' code may need to be generated on 11983 some platforms. These nodes are never used for C++-specific 11984 conversions, like conversions between pointers to different 11985 classes in an inheritance hierarchy. Any adjustments that need to 11986 be made in such cases are always indicated explicitly. Similarly, 11987 a user-defined conversion is never represented by a 11988 `CONVERT_EXPR'; instead, the function calls are made explicit. 11989 11990`FIXED_CONVERT_EXPR' 11991 These nodes are used to represent conversions that involve 11992 fixed-point values. For example, from a fixed-point value to 11993 another fixed-point value, from an integer to a fixed-point value, 11994 from a fixed-point value to an integer, from a floating-point 11995 value to a fixed-point value, or from a fixed-point value to a 11996 floating-point value. 11997 11998`LSHIFT_EXPR' 11999`RSHIFT_EXPR' 12000 These nodes represent left and right shifts, respectively. The 12001 first operand is the value to shift; it will always be of integral 12002 type. The second operand is an expression for the number of bits 12003 by which to shift. Right shift should be treated as arithmetic, 12004 i.e., the high-order bits should be zero-filled when the 12005 expression has unsigned type and filled with the sign bit when the 12006 expression has signed type. Note that the result is undefined if 12007 the second operand is larger than or equal to the first operand's 12008 type size. Unlike most nodes, these can have a vector as first 12009 operand and a scalar as second operand. 12010 12011`BIT_IOR_EXPR' 12012`BIT_XOR_EXPR' 12013`BIT_AND_EXPR' 12014 These nodes represent bitwise inclusive or, bitwise exclusive or, 12015 and bitwise and, respectively. Both operands will always have 12016 integral type. 12017 12018`TRUTH_ANDIF_EXPR' 12019`TRUTH_ORIF_EXPR' 12020 These nodes represent logical "and" and logical "or", respectively. 12021 These operators are not strict; i.e., the second operand is 12022 evaluated only if the value of the expression is not determined by 12023 evaluation of the first operand. The type of the operands and 12024 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 12025 12026`TRUTH_AND_EXPR' 12027`TRUTH_OR_EXPR' 12028`TRUTH_XOR_EXPR' 12029 These nodes represent logical and, logical or, and logical 12030 exclusive or. They are strict; both arguments are always 12031 evaluated. There are no corresponding operators in C or C++, but 12032 the front end will sometimes generate these expressions anyhow, if 12033 it can tell that strictness does not matter. The type of the 12034 operands and that of the result are always of `BOOLEAN_TYPE' or 12035 `INTEGER_TYPE'. 12036 12037`POINTER_PLUS_EXPR' 12038 This node represents pointer arithmetic. The first operand is 12039 always a pointer/reference type. The second operand is always an 12040 unsigned integer type compatible with sizetype. This is the only 12041 binary arithmetic operand that can operate on pointer types. 12042 12043`PLUS_EXPR' 12044`MINUS_EXPR' 12045`MULT_EXPR' 12046 These nodes represent various binary arithmetic operations. 12047 Respectively, these operations are addition, subtraction (of the 12048 second operand from the first) and multiplication. Their operands 12049 may have either integral or floating type, but there will never be 12050 case in which one operand is of floating type and the other is of 12051 integral type. 12052 12053 The behavior of these operations on signed arithmetic overflow is 12054 controlled by the `flag_wrapv' and `flag_trapv' variables. 12055 12056`MULT_HIGHPART_EXPR' 12057 This node represents the "high-part" of a widening multiplication. 12058 For an integral type with B bits of precision, the result is the 12059 most significant B bits of the full 2B product. 12060 12061`RDIV_EXPR' 12062 This node represents a floating point division operation. 12063 12064`TRUNC_DIV_EXPR' 12065`FLOOR_DIV_EXPR' 12066`CEIL_DIV_EXPR' 12067`ROUND_DIV_EXPR' 12068 These nodes represent integer division operations that return an 12069 integer result. `TRUNC_DIV_EXPR' rounds towards zero, 12070 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR' 12071 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to 12072 the closest integer. Integer division in C and C++ is truncating, 12073 i.e. `TRUNC_DIV_EXPR'. 12074 12075 The behavior of these operations on signed arithmetic overflow, 12076 when dividing the minimum signed integer by minus one, is 12077 controlled by the `flag_wrapv' and `flag_trapv' variables. 12078 12079`TRUNC_MOD_EXPR' 12080`FLOOR_MOD_EXPR' 12081`CEIL_MOD_EXPR' 12082`ROUND_MOD_EXPR' 12083 These nodes represent the integer remainder or modulus operation. 12084 The integer modulus of two operands `a' and `b' is defined as `a - 12085 (a/b)*b' where the division calculated using the corresponding 12086 division operator. Hence for `TRUNC_MOD_EXPR' this definition 12087 assumes division using truncation towards zero, i.e. 12088 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 12089 division, i.e. `TRUNC_MOD_EXPR'. 12090 12091`EXACT_DIV_EXPR' 12092 The `EXACT_DIV_EXPR' code is used to represent integer divisions 12093 where the numerator is known to be an exact multiple of the 12094 denominator. This allows the backend to choose between the faster 12095 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the 12096 current target. 12097 12098`LT_EXPR' 12099`LE_EXPR' 12100`GT_EXPR' 12101`GE_EXPR' 12102`EQ_EXPR' 12103`NE_EXPR' 12104 These nodes represent the less than, less than or equal to, greater 12105 than, greater than or equal to, equal, and not equal comparison 12106 operators. The first and second operands will either be both of 12107 integral type, both of floating type or both of vector type. The 12108 result type of these expressions will always be of integral, 12109 boolean or signed integral vector type. These operations return 12110 the result type's zero value for false, the result type's one 12111 value for true, and a vector whose elements are zero (false) or 12112 minus one (true) for vectors. 12113 12114 For floating point comparisons, if we honor IEEE NaNs and either 12115 operand is NaN, then `NE_EXPR' always returns true and the 12116 remaining operators always return false. On some targets, 12117 comparisons against an IEEE NaN, other than equality and 12118 inequality, may generate a floating point exception. 12119 12120`ORDERED_EXPR' 12121`UNORDERED_EXPR' 12122 These nodes represent non-trapping ordered and unordered comparison 12123 operators. These operations take two floating point operands and 12124 determine whether they are ordered or unordered relative to each 12125 other. If either operand is an IEEE NaN, their comparison is 12126 defined to be unordered, otherwise the comparison is defined to be 12127 ordered. The result type of these expressions will always be of 12128 integral or boolean type. These operations return the result 12129 type's zero value for false, and the result type's one value for 12130 true. 12131 12132`UNLT_EXPR' 12133`UNLE_EXPR' 12134`UNGT_EXPR' 12135`UNGE_EXPR' 12136`UNEQ_EXPR' 12137`LTGT_EXPR' 12138 These nodes represent the unordered comparison operators. These 12139 operations take two floating point operands and determine whether 12140 the operands are unordered or are less than, less than or equal to, 12141 greater than, greater than or equal to, or equal respectively. For 12142 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN 12143 or the first operand is less than the second. With the possible 12144 exception of `LTGT_EXPR', all of these operations are guaranteed 12145 not to generate a floating point exception. The result type of 12146 these expressions will always be of integral or boolean type. 12147 These operations return the result type's zero value for false, 12148 and the result type's one value for true. 12149 12150`MODIFY_EXPR' 12151 These nodes represent assignment. The left-hand side is the first 12152 operand; the right-hand side is the second operand. The left-hand 12153 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or 12154 other lvalue. 12155 12156 These nodes are used to represent not only assignment with `=' but 12157 also compound assignments (like `+='), by reduction to `=' 12158 assignment. In other words, the representation for `i += 3' looks 12159 just like that for `i = i + 3'. 12160 12161`INIT_EXPR' 12162 These nodes are just like `MODIFY_EXPR', but are used only when a 12163 variable is initialized, rather than assigned to subsequently. 12164 This means that we can assume that the target of the 12165 initialization is not used in computing its own value; any 12166 reference to the lhs in computing the rhs is undefined. 12167 12168`COMPOUND_EXPR' 12169 These nodes represent comma-expressions. The first operand is an 12170 expression whose value is computed and thrown away prior to the 12171 evaluation of the second operand. The value of the entire 12172 expression is the value of the second operand. 12173 12174`COND_EXPR' 12175 These nodes represent `?:' expressions. The first operand is of 12176 boolean or integral type. If it evaluates to a nonzero value, the 12177 second operand should be evaluated, and returned as the value of 12178 the expression. Otherwise, the third operand is evaluated, and 12179 returned as the value of the expression. 12180 12181 The second operand must have the same type as the entire 12182 expression, unless it unconditionally throws an exception or calls 12183 a noreturn function, in which case it should have void type. The 12184 same constraints apply to the third operand. This allows array 12185 bounds checks to be represented conveniently as `(i >= 0 && i < 12186 10) ? i : abort()'. 12187 12188 As a GNU extension, the C language front-ends allow the second 12189 operand of the `?:' operator may be omitted in the source. For 12190 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x' 12191 is an expression without side-effects. In the tree 12192 representation, however, the second operand is always present, 12193 possibly protected by `SAVE_EXPR' if the first argument does cause 12194 side-effects. 12195 12196`CALL_EXPR' 12197 These nodes are used to represent calls to functions, including 12198 non-static member functions. `CALL_EXPR's are implemented as 12199 expression nodes with a variable number of operands. Rather than 12200 using `TREE_OPERAND' to extract them, it is preferable to use the 12201 specialized accessor macros and functions that operate 12202 specifically on `CALL_EXPR' nodes. 12203 12204 `CALL_EXPR_FN' returns a pointer to the function to call; it is 12205 always an expression whose type is a `POINTER_TYPE'. 12206 12207 The number of arguments to the call is returned by 12208 `call_expr_nargs', while the arguments themselves can be accessed 12209 with the `CALL_EXPR_ARG' macro. The arguments are zero-indexed 12210 and numbered left-to-right. You can iterate over the arguments 12211 using `FOR_EACH_CALL_EXPR_ARG', as in: 12212 12213 tree call, arg; 12214 call_expr_arg_iterator iter; 12215 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 12216 /* arg is bound to successive arguments of call. */ 12217 ...; 12218 12219 For non-static member functions, there will be an operand 12220 corresponding to the `this' pointer. There will always be 12221 expressions corresponding to all of the arguments, even if the 12222 function is declared with default arguments and some arguments are 12223 not explicitly provided at the call sites. 12224 12225 `CALL_EXPR's also have a `CALL_EXPR_STATIC_CHAIN' operand that is 12226 used to implement nested functions. This operand is otherwise 12227 null. 12228 12229`CLEANUP_POINT_EXPR' 12230 These nodes represent full-expressions. The single operand is an 12231 expression to evaluate. Any destructor calls engendered by the 12232 creation of temporaries during the evaluation of that expression 12233 should be performed immediately after the expression is evaluated. 12234 12235`CONSTRUCTOR' 12236 These nodes represent the brace-enclosed initializers for a 12237 structure or array. The first operand is reserved for use by the 12238 back end. The second operand is a `TREE_LIST'. If the 12239 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or 12240 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the 12241 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each 12242 node will be the expression used to initialize that field. 12243 12244 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then 12245 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an 12246 `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single 12247 `INTEGER_CST' indicates which element of the array (indexed from 12248 zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive 12249 range of elements to initialize. In both cases the `TREE_VALUE' 12250 is the corresponding initializer. It is re-evaluated for each 12251 element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE', 12252 then the initializer is for the next available array element. 12253 12254 In the front end, you should not depend on the fields appearing in 12255 any particular order. However, in the middle end, fields must 12256 appear in declaration order. You should not assume that all 12257 fields will be represented. Unrepresented fields will be set to 12258 zero. 12259 12260`COMPOUND_LITERAL_EXPR' 12261 These nodes represent ISO C99 compound literals. The 12262 `COMPOUND_LITERAL_EXPR_DECL_EXPR' is a `DECL_EXPR' containing an 12263 anonymous `VAR_DECL' for the unnamed object represented by the 12264 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a 12265 `CONSTRUCTOR' representing the brace-enclosed list of initializers 12266 in the compound literal. That anonymous `VAR_DECL' can also be 12267 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. 12268 12269`SAVE_EXPR' 12270 A `SAVE_EXPR' represents an expression (possibly involving 12271 side-effects) that is used more than once. The side-effects should 12272 occur only the first time the expression is evaluated. Subsequent 12273 uses should just reuse the computed value. The first operand to 12274 the `SAVE_EXPR' is the expression to evaluate. The side-effects 12275 should be executed where the `SAVE_EXPR' is first encountered in a 12276 depth-first preorder traversal of the expression tree. 12277 12278`TARGET_EXPR' 12279 A `TARGET_EXPR' represents a temporary object. The first operand 12280 is a `VAR_DECL' for the temporary variable. The second operand is 12281 the initializer for the temporary. The initializer is evaluated 12282 and, if non-void, copied (bitwise) into the temporary. If the 12283 initializer is void, that means that it will perform the 12284 initialization itself. 12285 12286 Often, a `TARGET_EXPR' occurs on the right-hand side of an 12287 assignment, or as the second operand to a comma-expression which is 12288 itself the right-hand side of an assignment, etc. In this case, 12289 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is 12290 "orphaned". For a normal `TARGET_EXPR' the temporary variable 12291 should be treated as an alias for the left-hand side of the 12292 assignment, rather than as a new temporary variable. 12293 12294 The third operand to the `TARGET_EXPR', if present, is a 12295 cleanup-expression (i.e., destructor call) for the temporary. If 12296 this expression is orphaned, then this expression must be executed 12297 when the statement containing this expression is complete. These 12298 cleanups must always be executed in the order opposite to that in 12299 which they were encountered. Note that if a temporary is created 12300 on one branch of a conditional operator (i.e., in the second or 12301 third operand to a `COND_EXPR'), the cleanup must be run only if 12302 that branch is actually executed. 12303 12304`VA_ARG_EXPR' 12305 This node is used to implement support for the C/C++ variable 12306 argument-list mechanism. It represents expressions like `va_arg 12307 (ap, type)'. Its `TREE_TYPE' yields the tree representation for 12308 `type' and its sole argument yields the representation for `ap'. 12309 12310 12311 12312File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 12313 1231411.6.4 Vectors 12315-------------- 12316 12317`VEC_LSHIFT_EXPR' 12318`VEC_RSHIFT_EXPR' 12319 These nodes represent whole vector left and right shifts, 12320 respectively. The first operand is the vector to shift; it will 12321 always be of vector type. The second operand is an expression for 12322 the number of bits by which to shift. Note that the result is 12323 undefined if the second operand is larger than or equal to the 12324 first operand's type size. 12325 12326`VEC_WIDEN_MULT_HI_EXPR' 12327`VEC_WIDEN_MULT_LO_EXPR' 12328 These nodes represent widening vector multiplication of the high 12329 and low parts of the two input vectors, respectively. Their 12330 operands are vectors that contain the same number of elements 12331 (`N') of the same integral type. The result is a vector that 12332 contains half as many elements, of an integral type whose size is 12333 twice as wide. In the case of `VEC_WIDEN_MULT_HI_EXPR' the high 12334 `N/2' elements of the two vector are multiplied to produce the 12335 vector of `N/2' products. In the case of `VEC_WIDEN_MULT_LO_EXPR' 12336 the low `N/2' elements of the two vector are multiplied to produce 12337 the vector of `N/2' products. 12338 12339`VEC_UNPACK_HI_EXPR' 12340`VEC_UNPACK_LO_EXPR' 12341 These nodes represent unpacking of the high and low parts of the 12342 input vector, respectively. The single operand is a vector that 12343 contains `N' elements of the same integral or floating point type. 12344 The result is a vector that contains half as many elements, of an 12345 integral or floating point type whose size is twice as wide. In 12346 the case of `VEC_UNPACK_HI_EXPR' the high `N/2' elements of the 12347 vector are extracted and widened (promoted). In the case of 12348 `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the vector are 12349 extracted and widened (promoted). 12350 12351`VEC_UNPACK_FLOAT_HI_EXPR' 12352`VEC_UNPACK_FLOAT_LO_EXPR' 12353 These nodes represent unpacking of the high and low parts of the 12354 input vector, where the values are converted from fixed point to 12355 floating point. The single operand is a vector that contains `N' 12356 elements of the same integral type. The result is a vector that 12357 contains half as many elements of a floating point type whose size 12358 is twice as wide. In the case of `VEC_UNPACK_HI_EXPR' the high 12359 `N/2' elements of the vector are extracted, converted and widened. 12360 In the case of `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the 12361 vector are extracted, converted and widened. 12362 12363`VEC_PACK_TRUNC_EXPR' 12364 This node represents packing of truncated elements of the two 12365 input vectors into the output vector. Input operands are vectors 12366 that contain the same number of elements of the same integral or 12367 floating point type. The result is a vector that contains twice 12368 as many elements of an integral or floating point type whose size 12369 is half as wide. The elements of the two vectors are demoted and 12370 merged (concatenated) to form the output vector. 12371 12372`VEC_PACK_SAT_EXPR' 12373 This node represents packing of elements of the two input vectors 12374 into the output vector using saturation. Input operands are 12375 vectors that contain the same number of elements of the same 12376 integral type. The result is a vector that contains twice as many 12377 elements of an integral type whose size is half as wide. The 12378 elements of the two vectors are demoted and merged (concatenated) 12379 to form the output vector. 12380 12381`VEC_PACK_FIX_TRUNC_EXPR' 12382 This node represents packing of elements of the two input vectors 12383 into the output vector, where the values are converted from 12384 floating point to fixed point. Input operands are vectors that 12385 contain the same number of elements of a floating point type. The 12386 result is a vector that contains twice as many elements of an 12387 integral type whose size is half as wide. The elements of the two 12388 vectors are merged (concatenated) to form the output vector. 12389 12390`VEC_COND_EXPR' 12391 These nodes represent `?:' expressions. The three operands must be 12392 vectors of the same size and number of elements. The second and 12393 third operands must have the same type as the entire expression. 12394 The first operand is of signed integral vector type. If an 12395 element of the first operand evaluates to a zero value, the 12396 corresponding element of the result is taken from the third 12397 operand. If it evaluates to a minus one value, it is taken from 12398 the second operand. It should never evaluate to any other value 12399 currently, but optimizations should not rely on that property. In 12400 contrast with a `COND_EXPR', all operands are always evaluated. 12401 12402 12403File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 12404 1240511.7 Statements 12406=============== 12407 12408Most statements in GIMPLE are assignment statements, represented by 12409`GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 12410a reference to a volatile object is converted into a `GIMPLE_ASSIGN'. 12411 12412 There are also several varieties of complex statements. 12413 12414* Menu: 12415 12416* Basic Statements:: 12417* Blocks:: 12418* Statement Sequences:: 12419* Empty Statements:: 12420* Jumps:: 12421* Cleanups:: 12422* OpenMP:: 12423 12424 12425File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 12426 1242711.7.1 Basic Statements 12428----------------------- 12429 12430`ASM_EXPR' 12431 Used to represent an inline assembly statement. For an inline 12432 assembly statement like: 12433 asm ("mov x, y"); 12434 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov 12435 x, y"'. If the original statement made use of the 12436 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and 12437 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the 12438 statement, represented as `STRING_CST' nodes. The 12439 extended-assembly syntax looks like: 12440 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 12441 The first string is the `ASM_STRING', containing the instruction 12442 template. The next two strings are the output and inputs, 12443 respectively; this statement has no clobbers. As this example 12444 indicates, "plain" assembly statements are merely a special case 12445 of extended assembly statements; they have no cv-qualifiers, 12446 outputs, inputs, or clobbers. All of the strings will be 12447 `NUL'-terminated, and will contain no embedded `NUL'-characters. 12448 12449 If the assembly statement is declared `volatile', or if the 12450 statement was not an extended assembly statement, and is therefore 12451 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold 12452 of the `ASM_EXPR'. 12453 12454`DECL_EXPR' 12455 Used to represent a local declaration. The `DECL_EXPR_DECL' macro 12456 can be used to obtain the entity declared. This declaration may 12457 be a `LABEL_DECL', indicating that the label declared is a local 12458 label. (As an extension, GCC allows the declaration of labels 12459 with scope.) In C, this declaration may be a `FUNCTION_DECL', 12460 indicating the use of the GCC nested function extension. For more 12461 information, *note Functions::. 12462 12463`LABEL_EXPR' 12464 Used to represent a label. The `LABEL_DECL' declared by this 12465 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The 12466 `IDENTIFIER_NODE' giving the name of the label can be obtained from 12467 the `LABEL_DECL' with `DECL_NAME'. 12468 12469`GOTO_EXPR' 12470 Used to represent a `goto' statement. The `GOTO_DESTINATION' will 12471 usually be a `LABEL_DECL'. However, if the "computed goto" 12472 extension has been used, the `GOTO_DESTINATION' will be an 12473 arbitrary expression indicating the destination. This expression 12474 will always have pointer type. 12475 12476`RETURN_EXPR' 12477 Used to represent a `return' statement. Operand 0 represents the 12478 value to return. It should either be the `RESULT_DECL' for the 12479 containing function, or a `MODIFY_EXPR' or `INIT_EXPR' setting the 12480 function's `RESULT_DECL'. It will be `NULL_TREE' if the statement 12481 was just 12482 return; 12483 12484`LOOP_EXPR' 12485 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' 12486 represents the body of the loop. It should be executed forever, 12487 unless an `EXIT_EXPR' is encountered. 12488 12489`EXIT_EXPR' 12490 These nodes represent conditional exits from the nearest enclosing 12491 `LOOP_EXPR'. The single operand is the condition; if it is 12492 nonzero, then the loop should be exited. An `EXIT_EXPR' will only 12493 appear within a `LOOP_EXPR'. 12494 12495`SWITCH_STMT' 12496 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 12497 the expression on which the switch is occurring. See the 12498 documentation for an `IF_STMT' for more information on the 12499 representation used for the condition. The `SWITCH_STMT_BODY' is 12500 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 12501 original type of switch expression as given in the source, before 12502 any compiler conversions. 12503 12504`CASE_LABEL_EXPR' 12505 Use to represent a `case' label, range of `case' labels, or a 12506 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a 12507 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then 12508 this is an ordinary `case' label. In this case, `CASE_LOW' is an 12509 expression giving the value of the label. Both `CASE_LOW' and 12510 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the 12511 same type as the condition expression in the switch statement. 12512 12513 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the 12514 statement is a range of case labels. Such statements originate 12515 with the extension that allows users to write things of the form: 12516 case 2 ... 5: 12517 The first value will be `CASE_LOW', while the second will be 12518 `CASE_HIGH'. 12519 12520 12521 12522File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 12523 1252411.7.2 Blocks 12525------------- 12526 12527Block scopes and the variables they declare in GENERIC are expressed 12528using the `BIND_EXPR' code, which in previous versions of GCC was 12529primarily used for the C statement-expression extension. 12530 12531 Variables in a block are collected into `BIND_EXPR_VARS' in 12532declaration order through their `TREE_CHAIN' field. Any runtime 12533initialization is moved out of `DECL_INITIAL' and into a statement in 12534the controlled block. When gimplifying from C or C++, this 12535initialization replaces the `DECL_STMT'. These variables will never 12536require cleanups. The scope of these variables is just the body 12537 12538 Variable-length arrays (VLAs) complicate this process, as their size 12539often refers to variables initialized earlier in the block. To handle 12540this, we currently split the block at that point, and move the VLA into 12541a new, inner `BIND_EXPR'. This strategy may change in the future. 12542 12543 A C++ program will usually contain more `BIND_EXPR's than there are 12544syntactic blocks in the source code, since several C++ constructs have 12545implicit scopes associated with them. On the other hand, although the 12546C++ front end uses pseudo-scopes to handle cleanups for objects with 12547destructors, these don't translate into the GIMPLE form; multiple 12548declarations at the same level use the same `BIND_EXPR'. 12549 12550 12551File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 12552 1255311.7.3 Statement Sequences 12554-------------------------- 12555 12556Multiple statements at the same nesting level are collected into a 12557`STATEMENT_LIST'. Statement lists are modified and traversed using the 12558interface in `tree-iterator.h'. 12559 12560 12561File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 12562 1256311.7.4 Empty Statements 12564----------------------- 12565 12566Whenever possible, statements with no effect are discarded. But if 12567they are nested within another construct which cannot be discarded for 12568some reason, they are instead replaced with an empty statement, 12569generated by `build_empty_stmt'. Initially, all empty statements were 12570shared, after the pattern of the Java front end, but this caused a lot 12571of trouble in practice. 12572 12573 An empty statement is represented as `(void)0'. 12574 12575 12576File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 12577 1257811.7.5 Jumps 12579------------ 12580 12581Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'. 12582 12583 The operand of a `GOTO_EXPR' must be either a label or a variable 12584containing the address to jump to. 12585 12586 The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL', 12587or a `MODIFY_EXPR' which sets the return value. It would be nice to 12588move the `MODIFY_EXPR' into a separate statement, but the special 12589return semantics in `expand_return' make that difficult. It may still 12590happen in the future, perhaps by moving most of that logic into 12591`expand_assignment'. 12592 12593 12594File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 12595 1259611.7.6 Cleanups 12597--------------- 12598 12599Destructors for local C++ objects and similar dynamic cleanups are 12600represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has 12601two operands, both of which are a sequence of statements to execute. 12602The first sequence is executed. When it completes the second sequence 12603is executed. 12604 12605 The first sequence may complete in the following ways: 12606 12607 1. Execute the last statement in the sequence and fall off the end. 12608 12609 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label 12610 outside the sequence. 12611 12612 3. Execute a return statement (`RETURN_EXPR'). 12613 12614 4. Throw an exception. This is currently not explicitly represented 12615 in GIMPLE. 12616 12617 12618 The second sequence is not executed if the first sequence completes by 12619calling `setjmp' or `exit' or any other function that does not return. 12620The second sequence is also not executed if the first sequence 12621completes via a non-local goto or a computed goto (in general the 12622compiler does not know whether such a goto statement exits the first 12623sequence or not, so we assume that it doesn't). 12624 12625 After the second sequence is executed, if it completes normally by 12626falling off the end, execution continues wherever the first sequence 12627would have continued, by falling off the end, or doing a goto, etc. 12628 12629 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 12630to appear on every edge out of the controlled block; this reduces the 12631freedom to move code across these edges. Therefore, the EH lowering 12632pass which runs before most of the optimization passes eliminates these 12633expressions by explicitly adding the cleanup to each edge. Rethrowing 12634the exception is represented using `RESX_EXPR'. 12635 12636 12637File: gccint.info, Node: OpenMP, Prev: Cleanups, Up: Statements 12638 1263911.7.7 OpenMP 12640------------- 12641 12642All the statements starting with `OMP_' represent directives and 12643clauses used by the OpenMP API `http://www.openmp.org/'. 12644 12645`OMP_PARALLEL' 12646 Represents `#pragma omp parallel [clause1 ... clauseN]'. It has 12647 four operands: 12648 12649 Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High 12650 GIMPLE forms. It contains the body of code to be executed by all 12651 the threads. During GIMPLE lowering, this operand becomes `NULL' 12652 and the body is emitted linearly after `OMP_PARALLEL'. 12653 12654 Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated 12655 with the directive. 12656 12657 Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it 12658 contains the `FUNCTION_DECL' for the function that will contain 12659 the body of the parallel region. 12660 12661 Operand `OMP_PARALLEL_DATA_ARG' is also created by 12662 `pass_lower_omp'. If there are shared variables to be communicated 12663 to the children threads, this operand will contain the `VAR_DECL' 12664 that contains all the shared values and variables. 12665 12666`OMP_FOR' 12667 Represents `#pragma omp for [clause1 ... clauseN]'. It has 5 12668 operands: 12669 12670 Operand `OMP_FOR_BODY' contains the loop body. 12671 12672 Operand `OMP_FOR_CLAUSES' is the list of clauses associated with 12673 the directive. 12674 12675 Operand `OMP_FOR_INIT' is the loop initialization code of the form 12676 `VAR = N1'. 12677 12678 Operand `OMP_FOR_COND' is the loop conditional expression of the 12679 form `VAR {<,>,<=,>=} N2'. 12680 12681 Operand `OMP_FOR_INCR' is the loop index increment of the form 12682 `VAR {+=,-=} INCR'. 12683 12684 Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands 12685 `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These 12686 side-effects are part of the `OMP_FOR' block but must be evaluated 12687 before the start of loop body. 12688 12689 The loop index variable `VAR' must be a signed integer variable, 12690 which is implicitly private to each thread. Bounds `N1' and `N2' 12691 and the increment expression `INCR' are required to be loop 12692 invariant integer expressions that are evaluated without any 12693 synchronization. The evaluation order, frequency of evaluation and 12694 side-effects are unspecified by the standard. 12695 12696`OMP_SECTIONS' 12697 Represents `#pragma omp sections [clause1 ... clauseN]'. 12698 12699 Operand `OMP_SECTIONS_BODY' contains the sections body, which in 12700 turn contains a set of `OMP_SECTION' nodes for each of the 12701 concurrent sections delimited by `#pragma omp section'. 12702 12703 Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated 12704 with the directive. 12705 12706`OMP_SECTION' 12707 Section delimiter for `OMP_SECTIONS'. 12708 12709`OMP_SINGLE' 12710 Represents `#pragma omp single'. 12711 12712 Operand `OMP_SINGLE_BODY' contains the body of code to be executed 12713 by a single thread. 12714 12715 Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated 12716 with the directive. 12717 12718`OMP_MASTER' 12719 Represents `#pragma omp master'. 12720 12721 Operand `OMP_MASTER_BODY' contains the body of code to be executed 12722 by the master thread. 12723 12724`OMP_ORDERED' 12725 Represents `#pragma omp ordered'. 12726 12727 Operand `OMP_ORDERED_BODY' contains the body of code to be 12728 executed in the sequential order dictated by the loop index 12729 variable. 12730 12731`OMP_CRITICAL' 12732 Represents `#pragma omp critical [name]'. 12733 12734 Operand `OMP_CRITICAL_BODY' is the critical section. 12735 12736 Operand `OMP_CRITICAL_NAME' is an optional identifier to label the 12737 critical section. 12738 12739`OMP_RETURN' 12740 This does not represent any OpenMP directive, it is an artificial 12741 marker to indicate the end of the body of an OpenMP. It is used by 12742 the flow graph (`tree-cfg.c') and OpenMP region building code 12743 (`omp-low.c'). 12744 12745`OMP_CONTINUE' 12746 Similarly, this instruction does not represent an OpenMP 12747 directive, it is used by `OMP_FOR' and `OMP_SECTIONS' to mark the 12748 place where the code needs to loop to the next iteration (in the 12749 case of `OMP_FOR') or the next section (in the case of 12750 `OMP_SECTIONS'). 12751 12752 In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'. 12753 But if there are cleanups that need to occur right after the 12754 looping body, it will be emitted between `OMP_CONTINUE' and 12755 `OMP_RETURN'. 12756 12757`OMP_ATOMIC' 12758 Represents `#pragma omp atomic'. 12759 12760 Operand 0 is the address at which the atomic operation is to be 12761 performed. 12762 12763 Operand 1 is the expression to evaluate. The gimplifier tries 12764 three alternative code generation strategies. Whenever possible, 12765 an atomic update built-in is used. If that fails, a 12766 compare-and-swap loop is attempted. If that also fails, a regular 12767 critical section around the expression is used. 12768 12769`OMP_CLAUSE' 12770 Represents clauses associated with one of the `OMP_' directives. 12771 Clauses are represented by separate sub-codes defined in `tree.h'. 12772 Clauses codes can be one of: `OMP_CLAUSE_PRIVATE', 12773 `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE', 12774 `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN', 12775 `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF', 12776 `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE', 12777 `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT', 12778 `OMP_CLAUSE_REDUCTION', `OMP_CLAUSE_COLLAPSE', `OMP_CLAUSE_UNTIED', 12779 `OMP_CLAUSE_FINAL', and `OMP_CLAUSE_MERGEABLE'. Each code 12780 represents the corresponding OpenMP clause. 12781 12782 Clauses associated with the same directive are chained together 12783 via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of 12784 variables are restricted to exactly one, accessed with 12785 `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same 12786 clause `C' need to be represented as multiple `C' clauses chained 12787 together. This facilitates adding new clauses during compilation. 12788 12789 12790 12791File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 12792 1279311.8 Functions 12794============== 12795 12796A function is represented by a `FUNCTION_DECL' node. It stores the 12797basic pieces of the function such as body, parameters, and return type 12798as well as information on the surrounding context, visibility, and 12799linkage. 12800 12801* Menu: 12802 12803* Function Basics:: Function names, body, and parameters. 12804* Function Properties:: Context, linkage, etc. 12805 12806 12807File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 12808 1280911.8.1 Function Basics 12810---------------------- 12811 12812A function has four core parts: the name, the parameters, the result, 12813and the body. The following macros and functions access these parts of 12814a `FUNCTION_DECL' as well as other basic features: 12815`DECL_NAME' 12816 This macro returns the unqualified name of the function, as an 12817 `IDENTIFIER_NODE'. For an instantiation of a function template, 12818 the `DECL_NAME' is the unqualified name of the template, not 12819 something like `f<int>'. The value of `DECL_NAME' is undefined 12820 when used on a constructor, destructor, overloaded operator, or 12821 type-conversion operator, or any function that is implicitly 12822 generated by the compiler. See below for macros that can be used 12823 to distinguish these cases. 12824 12825`DECL_ASSEMBLER_NAME' 12826 This macro returns the mangled name of the function, also an 12827 `IDENTIFIER_NODE'. This name does not contain leading underscores 12828 on systems that prefix all identifiers with underscores. The 12829 mangled name is computed in the same way on all platforms; if 12830 special processing is required to deal with the object file format 12831 used on a particular platform, it is the responsibility of the 12832 back end to perform those modifications. (Of course, the back end 12833 should not modify `DECL_ASSEMBLER_NAME' itself.) 12834 12835 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be 12836 allocated (for the mangled name of the entity) so it should be used 12837 only when emitting assembly code. It should not be used within the 12838 optimizers to determine whether or not two declarations are the 12839 same, even though some of the existing optimizers do use it in 12840 that way. These uses will be removed over time. 12841 12842`DECL_ARGUMENTS' 12843 This macro returns the `PARM_DECL' for the first argument to the 12844 function. Subsequent `PARM_DECL' nodes can be obtained by 12845 following the `TREE_CHAIN' links. 12846 12847`DECL_RESULT' 12848 This macro returns the `RESULT_DECL' for the function. 12849 12850`DECL_SAVED_TREE' 12851 This macro returns the complete body of the function. 12852 12853`TREE_TYPE' 12854 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the 12855 function. 12856 12857`DECL_INITIAL' 12858 A function that has a definition in the current translation unit 12859 will have a non-`NULL' `DECL_INITIAL'. However, back ends should 12860 not make use of the particular value given by `DECL_INITIAL'. 12861 12862 It should contain a tree of `BLOCK' nodes that mirrors the scopes 12863 that variables are bound in the function. Each block contains a 12864 list of decls declared in a basic block, a pointer to a chain of 12865 blocks at the next lower scope level, then a pointer to the next 12866 block at the same level and a backpointer to the parent `BLOCK' or 12867 `FUNCTION_DECL'. So given a function as follows: 12868 12869 void foo() 12870 { 12871 int a; 12872 { 12873 int b; 12874 } 12875 int c; 12876 } 12877 12878 you would get the following: 12879 12880 tree foo = FUNCTION_DECL; 12881 tree decl_a = VAR_DECL; 12882 tree decl_b = VAR_DECL; 12883 tree decl_c = VAR_DECL; 12884 tree block_a = BLOCK; 12885 tree block_b = BLOCK; 12886 tree block_c = BLOCK; 12887 BLOCK_VARS(block_a) = decl_a; 12888 BLOCK_SUBBLOCKS(block_a) = block_b; 12889 BLOCK_CHAIN(block_a) = block_c; 12890 BLOCK_SUPERCONTEXT(block_a) = foo; 12891 BLOCK_VARS(block_b) = decl_b; 12892 BLOCK_SUPERCONTEXT(block_b) = block_a; 12893 BLOCK_VARS(block_c) = decl_c; 12894 BLOCK_SUPERCONTEXT(block_c) = foo; 12895 DECL_INITIAL(foo) = block_a; 12896 12897 12898 12899File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 12900 1290111.8.2 Function Properties 12902-------------------------- 12903 12904To determine the scope of a function, you can use the `DECL_CONTEXT' 12905macro. This macro will return the class (either a `RECORD_TYPE' or a 12906`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 12907is a member. For a virtual function, this macro returns the class in 12908which the function was actually defined, not the base class in which 12909the virtual declaration occurred. 12910 12911 In C, the `DECL_CONTEXT' for a function maybe another function. This 12912representation indicates that the GNU nested function extension is in 12913use. For details on the semantics of nested functions, see the GCC 12914Manual. The nested function can refer to local variables in its 12915containing function. Such references are not explicitly marked in the 12916tree structure; back ends must look at the `DECL_CONTEXT' for the 12917referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced 12918`VAR_DECL' is not the same as the function currently being processed, 12919and neither `DECL_EXTERNAL' nor `TREE_STATIC' hold, then the reference 12920is to a local variable in a containing function, and the back end must 12921take appropriate action. 12922 12923`DECL_EXTERNAL' 12924 This predicate holds if the function is undefined. 12925 12926`TREE_PUBLIC' 12927 This predicate holds if the function has external linkage. 12928 12929`TREE_STATIC' 12930 This predicate holds if the function has been defined. 12931 12932`TREE_THIS_VOLATILE' 12933 This predicate holds if the function does not return normally. 12934 12935`TREE_READONLY' 12936 This predicate holds if the function can only read its arguments. 12937 12938`DECL_PURE_P' 12939 This predicate holds if the function can only read its arguments, 12940 but may also read global memory. 12941 12942`DECL_VIRTUAL_P' 12943 This predicate holds if the function is virtual. 12944 12945`DECL_ARTIFICIAL' 12946 This macro holds if the function was implicitly generated by the 12947 compiler, rather than explicitly declared. In addition to 12948 implicitly generated class member functions, this macro holds for 12949 the special functions created to implement static initialization 12950 and destruction, to compute run-time type information, and so 12951 forth. 12952 12953`DECL_FUNCTION_SPECIFIC_TARGET' 12954 This macro returns a tree node that holds the target options that 12955 are to be used to compile this particular function or `NULL_TREE' 12956 if the function is to be compiled with the target options 12957 specified on the command line. 12958 12959`DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 12960 This macro returns a tree node that holds the optimization options 12961 that are to be used to compile this particular function or 12962 `NULL_TREE' if the function is to be compiled with the 12963 optimization options specified on the command line. 12964 12965 12966 12967File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 12968 1296911.9 Language-dependent trees 12970============================= 12971 12972Front ends may wish to keep some state associated with various GENERIC 12973trees while parsing. To support this, trees provide a set of flags 12974that may be used by the front end. They are accessed using 12975`TREE_LANG_FLAG_n' where `n' is currently 0 through 6. 12976 12977 If necessary, a front end can use some language-dependent tree codes 12978in its GENERIC representation, so long as it provides a hook for 12979converting them to GIMPLE and doesn't expect them to work with any 12980(hypothetical) optimizers that run before the conversion to GIMPLE. The 12981intermediate representation used while parsing C and C++ looks very 12982little like GENERIC, but the C and C++ gimplifier hooks are perfectly 12983happy to take it as input and spit out GIMPLE. 12984 12985 12986File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 12987 1298811.10 C and C++ Trees 12989===================== 12990 12991This section documents the internal representation used by GCC to 12992represent C and C++ source programs. When presented with a C or C++ 12993source program, GCC parses the program, performs semantic analysis 12994(including the generation of error messages), and then produces the 12995internal representation described here. This representation contains a 12996complete representation for the entire translation unit provided as 12997input to the front end. This representation is then typically processed 12998by a code-generator in order to produce machine code, but could also be 12999used in the creation of source browsers, intelligent editors, automatic 13000documentation generators, interpreters, and any other programs needing 13001the ability to process C or C++ code. 13002 13003 This section explains the internal representation. In particular, it 13004documents the internal representation for C and C++ source constructs, 13005and the macros, functions, and variables that can be used to access 13006these constructs. The C++ representation is largely a superset of the 13007representation used in the C front end. There is only one construct 13008used in C that does not appear in the C++ front end and that is the GNU 13009"nested function" extension. Many of the macros documented here do not 13010apply in C because the corresponding language constructs do not appear 13011in C. 13012 13013 The C and C++ front ends generate a mix of GENERIC trees and ones 13014specific to C and C++. These language-specific trees are higher-level 13015constructs than the ones in GENERIC to make the parser's job easier. 13016This section describes those trees that aren't part of GENERIC as well 13017as aspects of GENERIC trees that are treated in a language-specific 13018manner. 13019 13020 If you are developing a "back end", be it is a code-generator or some 13021other tool, that uses this representation, you may occasionally find 13022that you need to ask questions not easily answered by the functions and 13023macros available here. If that situation occurs, it is quite likely 13024that GCC already supports the functionality you desire, but that the 13025interface is simply not documented here. In that case, you should ask 13026the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 13027the functionality you require. Similarly, if you find yourself writing 13028functions that do not deal directly with your back end, but instead 13029might be useful to other people using the GCC front end, you should 13030submit your patches for inclusion in GCC. 13031 13032* Menu: 13033 13034* Types for C++:: Fundamental and aggregate types. 13035* Namespaces:: Namespaces. 13036* Classes:: Classes. 13037* Functions for C++:: Overloading and accessors for C++. 13038* Statements for C++:: Statements specific to C and C++. 13039* C++ Expressions:: From `typeid' to `throw'. 13040 13041 13042File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 13043 1304411.10.1 Types for C++ 13045--------------------- 13046 13047In C++, an array type is not qualified; rather the type of the array 13048elements is qualified. This situation is reflected in the intermediate 13049representation. The macros described here will always examine the 13050qualification of the underlying element type when applied to an array 13051type. (If the element type is itself an array, then the recursion 13052continues until a non-array type is found, and the qualification of this 13053type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the 13054type `const int ()[7]', denoting an array of seven `int's. 13055 13056 The following functions and macros deal with cv-qualification of types: 13057`cp_type_quals' 13058 This function returns the set of type qualifiers applied to this 13059 type. This value is `TYPE_UNQUALIFIED' if no qualifiers have been 13060 applied. The `TYPE_QUAL_CONST' bit is set if the type is 13061 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the 13062 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set 13063 if the type is `restrict'-qualified. 13064 13065`CP_TYPE_CONST_P' 13066 This macro holds if the type is `const'-qualified. 13067 13068`CP_TYPE_VOLATILE_P' 13069 This macro holds if the type is `volatile'-qualified. 13070 13071`CP_TYPE_RESTRICT_P' 13072 This macro holds if the type is `restrict'-qualified. 13073 13074`CP_TYPE_CONST_NON_VOLATILE_P' 13075 This predicate holds for a type that is `const'-qualified, but 13076 _not_ `volatile'-qualified; other cv-qualifiers are ignored as 13077 well: only the `const'-ness is tested. 13078 13079 13080 A few other macros and functions are usable with all types: 13081`TYPE_SIZE' 13082 The number of bits required to represent the type, represented as 13083 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 13084 `NULL_TREE'. 13085 13086`TYPE_ALIGN' 13087 The alignment of the type, in bits, represented as an `int'. 13088 13089`TYPE_NAME' 13090 This macro returns a declaration (in the form of a `TYPE_DECL') for 13091 the type. (Note this macro does _not_ return an 13092 `IDENTIFIER_NODE', as you might expect, given its name!) You can 13093 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 13094 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 13095 that is not a built-in type, the result of a typedef, or a named 13096 class type. 13097 13098`CP_INTEGRAL_TYPE' 13099 This predicate holds if the type is an integral type. Notice that 13100 in C++, enumerations are _not_ integral types. 13101 13102`ARITHMETIC_TYPE_P' 13103 This predicate holds if the type is an integral type (in the C++ 13104 sense) or a floating point type. 13105 13106`CLASS_TYPE_P' 13107 This predicate holds for a class-type. 13108 13109`TYPE_BUILT_IN' 13110 This predicate holds for a built-in type. 13111 13112`TYPE_PTRDATAMEM_P' 13113 This predicate holds if the type is a pointer to data member. 13114 13115`TYPE_PTR_P' 13116 This predicate holds if the type is a pointer type, and the 13117 pointee is not a data member. 13118 13119`TYPE_PTRFN_P' 13120 This predicate holds for a pointer to function type. 13121 13122`TYPE_PTROB_P' 13123 This predicate holds for a pointer to object type. Note however 13124 that it does not hold for the generic pointer to object type `void 13125 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object 13126 type as well as `void *'. 13127 13128 13129 The table below describes types specific to C and C++ as well as 13130language-dependent info about GENERIC types. 13131 13132`POINTER_TYPE' 13133 Used to represent pointer types, and pointer to data member types. 13134 If `TREE_TYPE' is a pointer to data member type, then 13135 `TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 13136 of the form `T X::*', `TYPE_PTRMEM_CLASS_TYPE' will be the type 13137 `X', while `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'. 13138 13139`RECORD_TYPE' 13140 Used to represent `struct' and `class' types in C and C++. If 13141 `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 13142 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a 13143 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is 13144 the type of a function pointed to by the pointer-to-member 13145 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a 13146 class type. For more information, *note Classes::. 13147 13148`UNKNOWN_TYPE' 13149 This node is used to represent a type the knowledge of which is 13150 insufficient for a sound processing. 13151 13152`TYPENAME_TYPE' 13153 Used to represent a construct of the form `typename T::A'. The 13154 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for 13155 `A'. If the type is specified via a template-id, then 13156 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The 13157 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in 13158 support for the implicit typename extension; in which case the 13159 `TREE_TYPE' is a type node for the base-class. 13160 13161`TYPEOF_TYPE' 13162 Used to represent the `__typeof__' extension. The `TYPE_FIELDS' 13163 is the expression the type of which is being represented. 13164 13165 13166 13167File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 13168 1316911.10.2 Namespaces 13170------------------ 13171 13172The root of the entire intermediate representation is the variable 13173`global_namespace'. This is the namespace specified with `::' in C++ 13174source code. All other namespaces, types, variables, functions, and so 13175forth can be found starting with this namespace. 13176 13177 However, except for the fact that it is distinguished as the root of 13178the representation, the global namespace is no different from any other 13179namespace. Thus, in what follows, we describe namespaces generally, 13180rather than the global namespace in particular. 13181 13182 A namespace is represented by a `NAMESPACE_DECL' node. 13183 13184 The following macros and functions can be used on a `NAMESPACE_DECL': 13185 13186`DECL_NAME' 13187 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to 13188 the unqualified name of the name of the namespace (*note 13189 Identifiers::). The name of the global namespace is `::', even 13190 though in C++ the global namespace is unnamed. However, you 13191 should use comparison with `global_namespace', rather than 13192 `DECL_NAME' to determine whether or not a namespace is the global 13193 one. An unnamed namespace will have a `DECL_NAME' equal to 13194 `anonymous_namespace_name'. Within a single translation unit, all 13195 unnamed namespaces will have the same name. 13196 13197`DECL_CONTEXT' 13198 This macro returns the enclosing namespace. The `DECL_CONTEXT' for 13199 the `global_namespace' is `NULL_TREE'. 13200 13201`DECL_NAMESPACE_ALIAS' 13202 If this declaration is for a namespace alias, then 13203 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 13204 alias. 13205 13206 Do not attempt to use `cp_namespace_decls' for a namespace which is 13207 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you 13208 reach an ordinary, non-alias, namespace, and call 13209 `cp_namespace_decls' there. 13210 13211`DECL_NAMESPACE_STD_P' 13212 This predicate holds if the namespace is the special `::std' 13213 namespace. 13214 13215`cp_namespace_decls' 13216 This function will return the declarations contained in the 13217 namespace, including types, overloaded functions, other 13218 namespaces, and so forth. If there are no declarations, this 13219 function will return `NULL_TREE'. The declarations are connected 13220 through their `TREE_CHAIN' fields. 13221 13222 Although most entries on this list will be declarations, 13223 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE' 13224 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is 13225 unspecified; back ends should ignore this value. As with the 13226 other kinds of declarations returned by `cp_namespace_decls', the 13227 `TREE_CHAIN' will point to the next declaration in this list. 13228 13229 For more information on the kinds of declarations that can occur 13230 on this list, *Note Declarations::. Some declarations will not 13231 appear on this list. In particular, no `FIELD_DECL', 13232 `LABEL_DECL', or `PARM_DECL' nodes will appear here. 13233 13234 This function cannot be used with namespaces that have 13235 `DECL_NAMESPACE_ALIAS' set. 13236 13237 13238 13239File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 13240 1324111.10.3 Classes 13242--------------- 13243 13244Besides namespaces, the other high-level scoping construct in C++ is the 13245class. (Throughout this manual the term "class" is used to mean the 13246types referred to in the ANSI/ISO C++ Standard as classes; these include 13247types defined with the `class', `struct', and `union' keywords.) 13248 13249 A class type is represented by either a `RECORD_TYPE' or a 13250`UNION_TYPE'. A class declared with the `union' tag is represented by 13251a `UNION_TYPE', while classes declared with either the `struct' or the 13252`class' tag are represented by `RECORD_TYPE's. You can use the 13253`CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 13254type is a `class' as opposed to a `struct'. This macro will be true 13255only for classes declared with the `class' tag. 13256 13257 Almost all non-function members are available on the `TYPE_FIELDS' 13258list. Given one member, the next can be found by following the 13259`TREE_CHAIN'. You should not depend in any way on the order in which 13260fields appear on this list. All nodes on this list will be `DECL' 13261nodes. A `FIELD_DECL' is used to represent a non-static data member, a 13262`VAR_DECL' is used to represent a static data member, and a `TYPE_DECL' 13263is used to represent a type. Note that the `CONST_DECL' for an 13264enumeration constant will appear on this list, if the enumeration type 13265was declared in the class. (Of course, the `TYPE_DECL' for the 13266enumeration type will appear here as well.) There are no entries for 13267base classes on this list. In particular, there is no `FIELD_DECL' for 13268the "base-class portion" of an object. 13269 13270 The `TYPE_VFIELD' is a compiler-generated field used to point to 13271virtual function tables. It may or may not appear on the `TYPE_FIELDS' 13272list. However, back ends should handle the `TYPE_VFIELD' just like all 13273the entries on the `TYPE_FIELDS' list. 13274 13275 The function members are available on the `TYPE_METHODS' list. Again, 13276subsequent members are found by following the `TREE_CHAIN' field. If a 13277function is overloaded, each of the overloaded functions appears; no 13278`OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly 13279declared functions (including default constructors, copy constructors, 13280assignment operators, and destructors) will appear on this list as well. 13281 13282 Every class has an associated "binfo", which can be obtained with 13283`TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 13284given by `TYPE_BINFO' is the degenerate case, whereby every class is 13285considered to be its own base-class. The base binfos for a particular 13286binfo are held in a vector, whose length is obtained with 13287`BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 13288`BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use 13289`BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 13290`BINFO_BASE_BINFOS', but normally you do not need to use that. The 13291class type associated with a binfo is given by `BINFO_TYPE'. It is not 13292always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 13293and qualified types. Neither is it the case that `TYPE_BINFO 13294(BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y' 13295is a binfo representing a base-class `B' of a derived class `D', then 13296`BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be 13297`B' as its own base-class, rather than as a base-class of `D'. 13298 13299 The access to a base type can be found with `BINFO_BASE_ACCESS'. This 13300will produce `access_public_node', `access_private_node' or 13301`access_protected_node'. If bases are always public, 13302`BINFO_BASE_ACCESSES' may be `NULL'. 13303 13304 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 13305virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1' 13306to `BINFO_FLAG_6' can be used for language specific use. 13307 13308 The following macros can be used on a tree node representing a 13309class-type. 13310 13311`LOCAL_CLASS_P' 13312 This predicate holds if the class is local class _i.e._ declared 13313 inside a function body. 13314 13315`TYPE_POLYMORPHIC_P' 13316 This predicate holds if the class has at least one virtual function 13317 (declared or inherited). 13318 13319`TYPE_HAS_DEFAULT_CONSTRUCTOR' 13320 This predicate holds whenever its argument represents a class-type 13321 with default constructor. 13322 13323`CLASSTYPE_HAS_MUTABLE' 13324`TYPE_HAS_MUTABLE_P' 13325 These predicates hold for a class-type having a mutable data 13326 member. 13327 13328`CLASSTYPE_NON_POD_P' 13329 This predicate holds only for class-types that are not PODs. 13330 13331`TYPE_HAS_NEW_OPERATOR' 13332 This predicate holds for a class-type that defines `operator new'. 13333 13334`TYPE_HAS_ARRAY_NEW_OPERATOR' 13335 This predicate holds for a class-type for which `operator new[]' 13336 is defined. 13337 13338`TYPE_OVERLOADS_CALL_EXPR' 13339 This predicate holds for class-type for which the function call 13340 `operator()' is overloaded. 13341 13342`TYPE_OVERLOADS_ARRAY_REF' 13343 This predicate holds for a class-type that overloads `operator[]' 13344 13345`TYPE_OVERLOADS_ARROW' 13346 This predicate holds for a class-type for which `operator->' is 13347 overloaded. 13348 13349 13350 13351File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 13352 1335311.10.4 Functions for C++ 13354------------------------- 13355 13356A function is represented by a `FUNCTION_DECL' node. A set of 13357overloaded functions is sometimes represented by an `OVERLOAD' node. 13358 13359 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros 13360should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a 13361`TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an 13362`OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the 13363list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT' 13364are actually polymorphic; you can use them to work with `FUNCTION_DECL' 13365nodes as well as with overloads. In the case of a `FUNCTION_DECL', 13366`OVL_CURRENT' will always return the function itself, and `OVL_NEXT' 13367will always be `NULL_TREE'. 13368 13369 To determine the scope of a function, you can use the `DECL_CONTEXT' 13370macro. This macro will return the class (either a `RECORD_TYPE' or a 13371`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 13372is a member. For a virtual function, this macro returns the class in 13373which the function was actually defined, not the base class in which 13374the virtual declaration occurred. 13375 13376 If a friend function is defined in a class scope, the 13377`DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 13378it was defined. For example, in 13379 class C { friend void f() {} }; 13380 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the 13381`DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'. 13382 13383 The following macros and functions can be used on a `FUNCTION_DECL': 13384`DECL_MAIN_P' 13385 This predicate holds for a function that is the program entry point 13386 `::code'. 13387 13388`DECL_LOCAL_FUNCTION_P' 13389 This predicate holds if the function was declared at block scope, 13390 even though it has a global scope. 13391 13392`DECL_ANTICIPATED' 13393 This predicate holds if the function is a built-in function but its 13394 prototype is not yet explicitly declared. 13395 13396`DECL_EXTERN_C_FUNCTION_P' 13397 This predicate holds if the function is declared as an ``extern 13398 "C"'' function. 13399 13400`DECL_LINKONCE_P' 13401 This macro holds if multiple copies of this function may be 13402 emitted in various translation units. It is the responsibility of 13403 the linker to merge the various copies. Template instantiations 13404 are the most common example of functions for which 13405 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all 13406 translation units which require them, and then relies on the 13407 linker to remove duplicate instantiations. 13408 13409 FIXME: This macro is not yet implemented. 13410 13411`DECL_FUNCTION_MEMBER_P' 13412 This macro holds if the function is a member of a class, rather 13413 than a member of a namespace. 13414 13415`DECL_STATIC_FUNCTION_P' 13416 This predicate holds if the function a static member function. 13417 13418`DECL_NONSTATIC_MEMBER_FUNCTION_P' 13419 This macro holds for a non-static member function. 13420 13421`DECL_CONST_MEMFUNC_P' 13422 This predicate holds for a `const'-member function. 13423 13424`DECL_VOLATILE_MEMFUNC_P' 13425 This predicate holds for a `volatile'-member function. 13426 13427`DECL_CONSTRUCTOR_P' 13428 This macro holds if the function is a constructor. 13429 13430`DECL_NONCONVERTING_P' 13431 This predicate holds if the constructor is a non-converting 13432 constructor. 13433 13434`DECL_COMPLETE_CONSTRUCTOR_P' 13435 This predicate holds for a function which is a constructor for an 13436 object of a complete type. 13437 13438`DECL_BASE_CONSTRUCTOR_P' 13439 This predicate holds for a function which is a constructor for a 13440 base class sub-object. 13441 13442`DECL_COPY_CONSTRUCTOR_P' 13443 This predicate holds for a function which is a copy-constructor. 13444 13445`DECL_DESTRUCTOR_P' 13446 This macro holds if the function is a destructor. 13447 13448`DECL_COMPLETE_DESTRUCTOR_P' 13449 This predicate holds if the function is the destructor for an 13450 object a complete type. 13451 13452`DECL_OVERLOADED_OPERATOR_P' 13453 This macro holds if the function is an overloaded operator. 13454 13455`DECL_CONV_FN_P' 13456 This macro holds if the function is a type-conversion operator. 13457 13458`DECL_GLOBAL_CTOR_P' 13459 This predicate holds if the function is a file-scope initialization 13460 function. 13461 13462`DECL_GLOBAL_DTOR_P' 13463 This predicate holds if the function is a file-scope finalization 13464 function. 13465 13466`DECL_THUNK_P' 13467 This predicate holds if the function is a thunk. 13468 13469 These functions represent stub code that adjusts the `this' pointer 13470 and then jumps to another function. When the jumped-to function 13471 returns, control is transferred directly to the caller, without 13472 returning to the thunk. The first parameter to the thunk is 13473 always the `this' pointer; the thunk should add `THUNK_DELTA' to 13474 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) 13475 13476 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the 13477 adjusted `this' pointer must be adjusted again. The complete 13478 calculation is given by the following pseudo-code: 13479 13480 this += THUNK_DELTA 13481 if (THUNK_VCALL_OFFSET) 13482 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 13483 13484 Finally, the thunk should jump to the location given by 13485 `DECL_INITIAL'; this will always be an expression for the address 13486 of a function. 13487 13488`DECL_NON_THUNK_FUNCTION_P' 13489 This predicate holds if the function is _not_ a thunk function. 13490 13491`GLOBAL_INIT_PRIORITY' 13492 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then 13493 this gives the initialization priority for the function. The 13494 linker will arrange that all functions for which 13495 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 13496 before `main' is called. When the program exits, all functions for 13497 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 13498 13499`TYPE_RAISES_EXCEPTIONS' 13500 This macro returns the list of exceptions that a (member-)function 13501 can raise. The returned list, if non `NULL', is comprised of nodes 13502 whose `TREE_VALUE' represents a type. 13503 13504`TYPE_NOTHROW_P' 13505 This predicate holds when the exception-specification of its 13506 arguments is of the form ``()''. 13507 13508`DECL_ARRAY_DELETE_OPERATOR_P' 13509 This predicate holds if the function an overloaded `operator 13510 delete[]'. 13511 13512 13513 13514File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 13515 1351611.10.5 Statements for C++ 13517-------------------------- 13518 13519A function that has a definition in the current translation unit will 13520have a non-`NULL' `DECL_INITIAL'. However, back ends should not make 13521use of the particular value given by `DECL_INITIAL'. 13522 13523 The `DECL_SAVED_TREE' macro will give the complete body of the 13524function. 13525 1352611.10.5.1 Statements 13527.................... 13528 13529There are tree nodes corresponding to all of the source-level statement 13530constructs, used within the C and C++ frontends. These are enumerated 13531here, together with a list of the various macros that can be used to 13532obtain information about them. There are a few macros that can be used 13533with all statements: 13534 13535`STMT_IS_FULL_EXPR_P' 13536 In C++, statements normally constitute "full expressions"; 13537 temporaries created during a statement are destroyed when the 13538 statement is complete. However, G++ sometimes represents 13539 expressions by statements; these statements will not have 13540 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such 13541 statements should be destroyed when the innermost enclosing 13542 statement with `STMT_IS_FULL_EXPR_P' set is exited. 13543 13544 13545 Here is the list of the various statement nodes, and the macros used to 13546access them. This documentation describes the use of these nodes in 13547non-template functions (including instantiations of template functions). 13548In template functions, the same nodes are used, but sometimes in 13549slightly different ways. 13550 13551 Many of the statements have substatements. For example, a `while' 13552loop will have a body, which is itself a statement. If the substatement 13553is `NULL_TREE', it is considered equivalent to a statement consisting 13554of a single `;', i.e., an expression statement in which the expression 13555has been omitted. A substatement may in fact be a list of statements, 13556connected via their `TREE_CHAIN's. So, you should always process the 13557statement tree by looping over substatements, like this: 13558 void process_stmt (stmt) 13559 tree stmt; 13560 { 13561 while (stmt) 13562 { 13563 switch (TREE_CODE (stmt)) 13564 { 13565 case IF_STMT: 13566 process_stmt (THEN_CLAUSE (stmt)); 13567 /* More processing here. */ 13568 break; 13569 13570 ... 13571 } 13572 13573 stmt = TREE_CHAIN (stmt); 13574 } 13575 } 13576 In other words, while the `then' clause of an `if' statement in C++ 13577can be only one statement (although that one statement may be a 13578compound statement), the intermediate representation will sometimes use 13579several statements chained together. 13580 13581`BREAK_STMT' 13582 Used to represent a `break' statement. There are no additional 13583 fields. 13584 13585`CLEANUP_STMT' 13586 Used to represent an action that should take place upon exit from 13587 the enclosing scope. Typically, these actions are calls to 13588 destructors for local objects, but back ends cannot rely on this 13589 fact. If these nodes are in fact representing such destructors, 13590 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, 13591 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the 13592 `CLEANUP_EXPR' is the expression to execute. The cleanups 13593 executed on exit from a scope should be run in the reverse order 13594 of the order in which the associated `CLEANUP_STMT's were 13595 encountered. 13596 13597`CONTINUE_STMT' 13598 Used to represent a `continue' statement. There are no additional 13599 fields. 13600 13601`CTOR_STMT' 13602 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if 13603 `CTOR_END_P' holds of the main body of a constructor. See also 13604 `SUBOBJECT' for more information on how to use these nodes. 13605 13606`DO_STMT' 13607 Used to represent a `do' loop. The body of the loop is given by 13608 `DO_BODY' while the termination condition for the loop is given by 13609 `DO_COND'. The condition for a `do'-statement is always an 13610 expression. 13611 13612`EMPTY_CLASS_EXPR' 13613 Used to represent a temporary object of a class with no data whose 13614 address is never taken. (All such objects are interchangeable.) 13615 The `TREE_TYPE' represents the type of the object. 13616 13617`EXPR_STMT' 13618 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to 13619 obtain the expression. 13620 13621`FOR_STMT' 13622 Used to represent a `for' statement. The `FOR_INIT_STMT' is the 13623 initialization statement for the loop. The `FOR_COND' is the 13624 termination condition. The `FOR_EXPR' is the expression executed 13625 right before the `FOR_COND' on each loop iteration; often, this 13626 expression increments a counter. The body of the loop is given by 13627 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return 13628 statements, while `FOR_COND' and `FOR_EXPR' return expressions. 13629 13630`HANDLER' 13631 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the 13632 type of exception that will be caught by this handler; it is equal 13633 (by pointer equality) to `NULL' if this handler is for all types. 13634 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and 13635 `HANDLER_BODY' is the code for the block itself. 13636 13637`IF_STMT' 13638 Used to represent an `if' statement. The `IF_COND' is the 13639 expression. 13640 13641 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a 13642 statement (usually a `DECL_STMT'). Each time the condition is 13643 evaluated, the statement should be executed. Then, the 13644 `TREE_VALUE' should be used as the conditional expression itself. 13645 This representation is used to handle C++ code like this: 13646 13647 C++ distinguishes between this and `COND_EXPR' for handling 13648 templates. 13649 13650 if (int i = 7) ... 13651 13652 where there is a new local variable (or variables) declared within 13653 the condition. 13654 13655 The `THEN_CLAUSE' represents the statement given by the `then' 13656 condition, while the `ELSE_CLAUSE' represents the statement given 13657 by the `else' condition. 13658 13659`SUBOBJECT' 13660 In a constructor, these nodes are used to mark the point at which a 13661 subobject of `this' is fully constructed. If, after this point, an 13662 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is 13663 encountered, the `SUBOBJECT_CLEANUP' must be executed. The 13664 cleanups must be executed in the reverse order in which they 13665 appear. 13666 13667`SWITCH_STMT' 13668 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 13669 the expression on which the switch is occurring. See the 13670 documentation for an `IF_STMT' for more information on the 13671 representation used for the condition. The `SWITCH_STMT_BODY' is 13672 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 13673 original type of switch expression as given in the source, before 13674 any compiler conversions. 13675 13676`TRY_BLOCK' 13677 Used to represent a `try' block. The body of the try block is 13678 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' 13679 node. The first handler is given by `TRY_HANDLERS'. Subsequent 13680 handlers are obtained by following the `TREE_CHAIN' link from one 13681 handler to the next. The body of the handler is given by 13682 `HANDLER_BODY'. 13683 13684 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' 13685 will not be a `HANDLER' node. Instead, it will be an expression 13686 that should be executed if an exception is thrown in the try 13687 block. It must rethrow the exception after executing that code. 13688 And, if an exception is thrown while the expression is executing, 13689 `terminate' must be called. 13690 13691`USING_STMT' 13692 Used to represent a `using' directive. The namespace is given by 13693 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 13694 is needed inside template functions, to implement using directives 13695 during instantiation. 13696 13697`WHILE_STMT' 13698 Used to represent a `while' loop. The `WHILE_COND' is the 13699 termination condition for the loop. See the documentation for an 13700 `IF_STMT' for more information on the representation used for the 13701 condition. 13702 13703 The `WHILE_BODY' is the body of the loop. 13704 13705 13706 13707File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 13708 1370911.10.6 C++ Expressions 13710----------------------- 13711 13712This section describes expressions specific to the C and C++ front ends. 13713 13714`TYPEID_EXPR' 13715 Used to represent a `typeid' expression. 13716 13717`NEW_EXPR' 13718`VEC_NEW_EXPR' 13719 Used to represent a call to `new' and `new[]' respectively. 13720 13721`DELETE_EXPR' 13722`VEC_DELETE_EXPR' 13723 Used to represent a call to `delete' and `delete[]' respectively. 13724 13725`MEMBER_REF' 13726 Represents a reference to a member of a class. 13727 13728`THROW_EXPR' 13729 Represents an instance of `throw' in the program. Operand 0, 13730 which is the expression to throw, may be `NULL_TREE'. 13731 13732`AGGR_INIT_EXPR' 13733 An `AGGR_INIT_EXPR' represents the initialization as the return 13734 value of a function call, or as the result of a constructor. An 13735 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the 13736 second operand of a `TARGET_EXPR'. `AGGR_INIT_EXPR's have a 13737 representation similar to that of `CALL_EXPR's. You can use the 13738 `AGGR_INIT_EXPR_FN' and `AGGR_INIT_EXPR_ARG' macros to access the 13739 function to call and the arguments to pass. 13740 13741 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the 13742 initialization is via a constructor call. The address of the 13743 `AGGR_INIT_EXPR_SLOT' operand, which is always a `VAR_DECL', is 13744 taken, and this value replaces the first argument in the argument 13745 list. 13746 13747 In either case, the expression is void. 13748 13749 13750 13751File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 13752 1375311.11 Java Trees 13754================ 13755 13756 13757File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 13758 1375912 GIMPLE 13760********* 13761 13762GIMPLE is a three-address representation derived from GENERIC by 13763breaking down GENERIC expressions into tuples of no more than 3 13764operands (with some exceptions like function calls). GIMPLE was 13765heavily influenced by the SIMPLE IL used by the McCAT compiler project 13766at McGill University, though we have made some different choices. For 13767one thing, SIMPLE doesn't support `goto'. 13768 13769 Temporaries are introduced to hold intermediate values needed to 13770compute complex expressions. Additionally, all the control structures 13771used in GENERIC are lowered into conditional jumps, lexical scopes are 13772removed and exception regions are converted into an on the side 13773exception region tree. 13774 13775 The compiler pass which converts GENERIC into GIMPLE is referred to as 13776the `gimplifier'. The gimplifier works recursively, generating GIMPLE 13777tuples out of the original GENERIC expressions. 13778 13779 One of the early implementation strategies used for the GIMPLE 13780representation was to use the same internal data structures used by 13781front ends to represent parse trees. This simplified implementation 13782because we could leverage existing functionality and interfaces. 13783However, GIMPLE is a much more restrictive representation than abstract 13784syntax trees (AST), therefore it does not require the full structural 13785complexity provided by the main tree data structure. 13786 13787 The GENERIC representation of a function is stored in the 13788`DECL_SAVED_TREE' field of the associated `FUNCTION_DECL' tree node. 13789It is converted to GIMPLE by a call to `gimplify_function_tree'. 13790 13791 If a front end wants to include language-specific tree codes in the 13792tree representation which it provides to the back end, it must provide a 13793definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 13794front end trees to GIMPLE. Usually such a hook will involve much of 13795the same code for expanding front end trees to RTL. This function can 13796return fully lowered GIMPLE, or it can return GENERIC trees and let the 13797main gimplifier lower them the rest of the way; this is often simpler. 13798GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 13799of the IL before the pass `pass_lower_cf'. High GIMPLE contains some 13800container statements like lexical scopes (represented by `GIMPLE_BIND') 13801and nested expressions (e.g., `GIMPLE_TRY'), while "Low GIMPLE" exposes 13802all of the implicit jumps for control and exception expressions 13803directly in the IL and EH region trees. 13804 13805 The C and C++ front ends currently convert directly from front end 13806trees to GIMPLE, and hand that off to the back end rather than first 13807converting to GENERIC. Their gimplifier hooks know about all the 13808`_STMT' nodes and how to convert them to GENERIC forms. There was some 13809work done on a genericization pass which would run first, but the 13810existence of `STMT_EXPR' meant that in order to convert all of the C 13811statements into GENERIC equivalents would involve walking the entire 13812tree anyway, so it was simpler to lower all the way. This might change 13813in the future if someone writes an optimization pass which would work 13814better with higher-level trees, but currently the optimizers all expect 13815GIMPLE. 13816 13817 You can request to dump a C-like representation of the GIMPLE form 13818with the flag `-fdump-tree-gimple'. 13819 13820* Menu: 13821 13822* Tuple representation:: 13823* GIMPLE instruction set:: 13824* GIMPLE Exception Handling:: 13825* Temporaries:: 13826* Operands:: 13827* Manipulating GIMPLE statements:: 13828* Tuple specific accessors:: 13829* GIMPLE sequences:: 13830* Sequence iterators:: 13831* Adding a new GIMPLE statement code:: 13832* Statement and operand traversals:: 13833 13834 13835File: gccint.info, Node: Tuple representation, Next: GIMPLE instruction set, Up: GIMPLE 13836 1383712.1 Tuple representation 13838========================= 13839 13840GIMPLE instructions are tuples of variable size divided in two groups: 13841a header describing the instruction and its locations, and a variable 13842length body with all the operands. Tuples are organized into a 13843hierarchy with 3 main classes of tuples. 13844 1384512.1.1 `gimple_statement_base' (gsbase) 13846--------------------------------------- 13847 13848This is the root of the hierarchy, it holds basic information needed by 13849most GIMPLE statements. There are some fields that may not be relevant 13850to every GIMPLE statement, but those were moved into the base structure 13851to take advantage of holes left by other fields (thus making the 13852structure more compact). The structure takes 4 words (32 bytes) on 64 13853bit hosts: 13854 13855Field Size (bits) 13856`code' 8 13857`subcode' 16 13858`no_warning' 1 13859`visited' 1 13860`nontemporal_move' 1 13861`plf' 2 13862`modified' 1 13863`has_volatile_ops' 1 13864`references_memory_p' 1 13865`uid' 32 13866`location' 32 13867`num_ops' 32 13868`bb' 64 13869`block' 63 13870Total size 32 bytes 13871 13872 * `code' Main identifier for a GIMPLE instruction. 13873 13874 * `subcode' Used to distinguish different variants of the same basic 13875 instruction or provide flags applicable to a given code. The 13876 `subcode' flags field has different uses depending on the code of 13877 the instruction, but mostly it distinguishes instructions of the 13878 same family. The most prominent use of this field is in 13879 assignments, where subcode indicates the operation done on the RHS 13880 of the assignment. For example, a = b + c is encoded as 13881 `GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 13882 13883 * `no_warning' Bitflag to indicate whether a warning has already 13884 been issued on this statement. 13885 13886 * `visited' General purpose "visited" marker. Set and cleared by 13887 each pass when needed. 13888 13889 * `nontemporal_move' Bitflag used in assignments that represent 13890 non-temporal moves. Although this bitflag is only used in 13891 assignments, it was moved into the base to take advantage of the 13892 bit holes left by the previous fields. 13893 13894 * `plf' Pass Local Flags. This 2-bit mask can be used as general 13895 purpose markers by any pass. Passes are responsible for clearing 13896 and setting these two flags accordingly. 13897 13898 * `modified' Bitflag to indicate whether the statement has been 13899 modified. Used mainly by the operand scanner to determine when to 13900 re-scan a statement for operands. 13901 13902 * `has_volatile_ops' Bitflag to indicate whether this statement 13903 contains operands that have been marked volatile. 13904 13905 * `references_memory_p' Bitflag to indicate whether this statement 13906 contains memory references (i.e., its operands are either global 13907 variables, or pointer dereferences or anything that must reside in 13908 memory). 13909 13910 * `uid' This is an unsigned integer used by passes that want to 13911 assign IDs to every statement. These IDs must be assigned and used 13912 by each pass. 13913 13914 * `location' This is a `location_t' identifier to specify source code 13915 location for this statement. It is inherited from the front end. 13916 13917 * `num_ops' Number of operands that this statement has. This 13918 specifies the size of the operand vector embedded in the tuple. 13919 Only used in some tuples, but it is declared in the base tuple to 13920 take advantage of the 32-bit hole left by the previous fields. 13921 13922 * `bb' Basic block holding the instruction. 13923 13924 * `block' Lexical block holding this statement. Also used for debug 13925 information generation. 13926 1392712.1.2 `gimple_statement_with_ops' 13928---------------------------------- 13929 13930This tuple is actually split in two: `gimple_statement_with_ops_base' 13931and `gimple_statement_with_ops'. This is needed to accommodate the way 13932the operand vector is allocated. The operand vector is defined to be an 13933array of 1 element. So, to allocate a dynamic number of operands, the 13934memory allocator (`gimple_alloc') simply allocates enough memory to 13935hold the structure itself plus `N - 1' operands which run "off the end" 13936of the structure. For example, to allocate space for a tuple with 3 13937operands, `gimple_alloc' reserves `sizeof (struct 13938gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 13939 13940 On the other hand, several fields in this tuple need to be shared with 13941the `gimple_statement_with_memory_ops' tuple. So, these common fields 13942are placed in `gimple_statement_with_ops_base' which is then inherited 13943from the other two tuples. 13944 13945`gsbase' 256 13946`def_ops' 64 13947`use_ops' 64 13948`op' `num_ops' * 64 13949Total size 48 + 8 * `num_ops' bytes 13950 13951 * `gsbase' Inherited from `struct gimple_statement_base'. 13952 13953 * `def_ops' Array of pointers into the operand array indicating all 13954 the slots that contain a variable written-to by the statement. 13955 This array is also used for immediate use chaining. Note that it 13956 would be possible to not rely on this array, but the changes 13957 required to implement this are pretty invasive. 13958 13959 * `use_ops' Similar to `def_ops' but for variables read by the 13960 statement. 13961 13962 * `op' Array of trees with `num_ops' slots. 13963 1396412.1.3 `gimple_statement_with_memory_ops' 13965----------------------------------------- 13966 13967This tuple is essentially identical to `gimple_statement_with_ops', 13968except that it contains 4 additional fields to hold vectors related 13969memory stores and loads. Similar to the previous case, the structure 13970is split in two to accommodate for the operand vector 13971(`gimple_statement_with_memory_ops_base' and 13972`gimple_statement_with_memory_ops'). 13973 13974Field Size (bits) 13975`gsbase' 256 13976`def_ops' 64 13977`use_ops' 64 13978`vdef_ops' 64 13979`vuse_ops' 64 13980`stores' 64 13981`loads' 64 13982`op' `num_ops' * 64 13983Total size 80 + 8 * `num_ops' bytes 13984 13985 * `vdef_ops' Similar to `def_ops' but for `VDEF' operators. There is 13986 one entry per memory symbol written by this statement. This is 13987 used to maintain the memory SSA use-def and def-def chains. 13988 13989 * `vuse_ops' Similar to `use_ops' but for `VUSE' operators. There is 13990 one entry per memory symbol loaded by this statement. This is used 13991 to maintain the memory SSA use-def chains. 13992 13993 * `stores' Bitset with all the UIDs for the symbols written-to by the 13994 statement. This is different than `vdef_ops' in that all the 13995 affected symbols are mentioned in this set. If memory 13996 partitioning is enabled, the `vdef_ops' vector will refer to memory 13997 partitions. Furthermore, no SSA information is stored in this set. 13998 13999 * `loads' Similar to `stores', but for memory loads. (Note that there 14000 is some amount of redundancy here, it should be possible to reduce 14001 memory utilization further by removing these sets). 14002 14003 All the other tuples are defined in terms of these three basic ones. 14004Each tuple will add some fields. The main gimple type is defined to be 14005the union of all these structures (`GTY' markers elided for clarity): 14006 14007 union gimple_statement_d 14008 { 14009 struct gimple_statement_base gsbase; 14010 struct gimple_statement_with_ops gsops; 14011 struct gimple_statement_with_memory_ops gsmem; 14012 struct gimple_statement_omp omp; 14013 struct gimple_statement_bind gimple_bind; 14014 struct gimple_statement_catch gimple_catch; 14015 struct gimple_statement_eh_filter gimple_eh_filter; 14016 struct gimple_statement_phi gimple_phi; 14017 struct gimple_statement_resx gimple_resx; 14018 struct gimple_statement_try gimple_try; 14019 struct gimple_statement_wce gimple_wce; 14020 struct gimple_statement_asm gimple_asm; 14021 struct gimple_statement_omp_critical gimple_omp_critical; 14022 struct gimple_statement_omp_for gimple_omp_for; 14023 struct gimple_statement_omp_parallel gimple_omp_parallel; 14024 struct gimple_statement_omp_task gimple_omp_task; 14025 struct gimple_statement_omp_sections gimple_omp_sections; 14026 struct gimple_statement_omp_single gimple_omp_single; 14027 struct gimple_statement_omp_continue gimple_omp_continue; 14028 struct gimple_statement_omp_atomic_load gimple_omp_atomic_load; 14029 struct gimple_statement_omp_atomic_store gimple_omp_atomic_store; 14030 }; 14031 14032 14033File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Tuple representation, Up: GIMPLE 14034 1403512.2 GIMPLE instruction set 14036=========================== 14037 14038The following table briefly describes the GIMPLE instruction set. 14039 14040Instruction High GIMPLE Low GIMPLE 14041`GIMPLE_ASM' x x 14042`GIMPLE_ASSIGN' x x 14043`GIMPLE_BIND' x 14044`GIMPLE_CALL' x x 14045`GIMPLE_CATCH' x 14046`GIMPLE_COND' x x 14047`GIMPLE_DEBUG' x x 14048`GIMPLE_EH_FILTER' x 14049`GIMPLE_GOTO' x x 14050`GIMPLE_LABEL' x x 14051`GIMPLE_NOP' x x 14052`GIMPLE_OMP_ATOMIC_LOAD' x x 14053`GIMPLE_OMP_ATOMIC_STORE' x x 14054`GIMPLE_OMP_CONTINUE' x x 14055`GIMPLE_OMP_CRITICAL' x x 14056`GIMPLE_OMP_FOR' x x 14057`GIMPLE_OMP_MASTER' x x 14058`GIMPLE_OMP_ORDERED' x x 14059`GIMPLE_OMP_PARALLEL' x x 14060`GIMPLE_OMP_RETURN' x x 14061`GIMPLE_OMP_SECTION' x x 14062`GIMPLE_OMP_SECTIONS' x x 14063`GIMPLE_OMP_SECTIONS_SWITCH' x x 14064`GIMPLE_OMP_SINGLE' x x 14065`GIMPLE_PHI' x 14066`GIMPLE_RESX' x 14067`GIMPLE_RETURN' x x 14068`GIMPLE_SWITCH' x x 14069`GIMPLE_TRY' x 14070 14071 14072File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 14073 1407412.3 Exception Handling 14075======================= 14076 14077Other exception handling constructs are represented using 14078`GIMPLE_TRY_CATCH'. `GIMPLE_TRY_CATCH' has two operands. The first 14079operand is a sequence of statements to execute. If executing these 14080statements does not throw an exception, then the second operand is 14081ignored. Otherwise, if an exception is thrown, then the second operand 14082of the `GIMPLE_TRY_CATCH' is checked. The second operand may have the 14083following forms: 14084 14085 1. A sequence of statements to execute. When an exception occurs, 14086 these statements are executed, and then the exception is rethrown. 14087 14088 2. A sequence of `GIMPLE_CATCH' statements. Each `GIMPLE_CATCH' has 14089 a list of applicable exception types and handler code. If the 14090 thrown exception matches one of the caught types, the associated 14091 handler code is executed. If the handler code falls off the 14092 bottom, execution continues after the original `GIMPLE_TRY_CATCH'. 14093 14094 3. A `GIMPLE_EH_FILTER' statement. This has a list of permitted 14095 exception types, and code to handle a match failure. If the 14096 thrown exception does not match one of the allowed types, the 14097 associated match failure code is executed. If the thrown exception 14098 does match, it continues unwinding the stack looking for the next 14099 handler. 14100 14101 14102 Currently throwing an exception is not directly represented in GIMPLE, 14103since it is implemented by calling a function. At some point in the 14104future we will want to add some way to express that the call will throw 14105an exception of a known type. 14106 14107 Just before running the optimizers, the compiler lowers the high-level 14108EH constructs above into a set of `goto's, magic labels, and EH 14109regions. Continuing to unwind at the end of a cleanup is represented 14110with a `GIMPLE_RESX'. 14111 14112 14113File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 14114 1411512.4 Temporaries 14116================ 14117 14118When gimplification encounters a subexpression that is too complex, it 14119creates a new temporary variable to hold the value of the 14120subexpression, and adds a new statement to initialize it before the 14121current statement. These special temporaries are known as `expression 14122temporaries', and are allocated using `get_formal_tmp_var'. The 14123compiler tries to always evaluate identical expressions into the same 14124temporary, to simplify elimination of redundant calculations. 14125 14126 We can only use expression temporaries when we know that it will not 14127be reevaluated before its value is used, and that it will not be 14128otherwise modified(1). Other temporaries can be allocated using 14129`get_initialized_tmp_var' or `create_tmp_var'. 14130 14131 Currently, an expression like `a = b + 5' is not reduced any further. 14132We tried converting it to something like 14133 T1 = b + 5; 14134 a = T1; 14135 but this bloated the representation for minimal benefit. However, a 14136variable which must live in memory cannot appear in an expression; its 14137value is explicitly loaded into a temporary first. Similarly, storing 14138the value of an expression to a memory variable goes through a 14139temporary. 14140 14141 ---------- Footnotes ---------- 14142 14143 (1) These restrictions are derived from those in Morgan 4.8. 14144 14145 14146File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 14147 1414812.5 Operands 14149============= 14150 14151In general, expressions in GIMPLE consist of an operation and the 14152appropriate number of simple operands; these operands must either be a 14153GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register 14154variable. More complex operands are factored out into temporaries, so 14155that 14156 a = b + c + d 14157 becomes 14158 T1 = b + c; 14159 a = T1 + d; 14160 14161 The same rule holds for arguments to a `GIMPLE_CALL'. 14162 14163 The target of an assignment is usually a variable, but can also be a 14164`MEM_REF' or a compound lvalue as described below. 14165 14166* Menu: 14167 14168* Compound Expressions:: 14169* Compound Lvalues:: 14170* Conditional Expressions:: 14171* Logical Operators:: 14172 14173 14174File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 14175 1417612.5.1 Compound Expressions 14177--------------------------- 14178 14179The left-hand side of a C comma expression is simply moved into a 14180separate statement. 14181 14182 14183File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 14184 1418512.5.2 Compound Lvalues 14186----------------------- 14187 14188Currently compound lvalues involving array and structure field 14189references are not broken down; an expression like `a.b[2] = 42' is not 14190reduced any further (though complex array subscripts are). This 14191restriction is a workaround for limitations in later optimizers; if we 14192were to convert this to 14193 14194 T1 = &a.b; 14195 T1[2] = 42; 14196 14197 alias analysis would not remember that the reference to `T1[2]' came 14198by way of `a.b', so it would think that the assignment could alias 14199another member of `a'; this broke `struct-alias-1.c'. Future optimizer 14200improvements may make this limitation unnecessary. 14201 14202 14203File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 14204 1420512.5.3 Conditional Expressions 14206------------------------------ 14207 14208A C `?:' expression is converted into an `if' statement with each 14209branch assigning to the same temporary. So, 14210 14211 a = b ? c : d; 14212 becomes 14213 if (b == 1) 14214 T1 = c; 14215 else 14216 T1 = d; 14217 a = T1; 14218 14219 The GIMPLE level if-conversion pass re-introduces `?:' expression, if 14220appropriate. It is used to vectorize loops with conditions using vector 14221conditional operations. 14222 14223 Note that in GIMPLE, `if' statements are represented using 14224`GIMPLE_COND', as described below. 14225 14226 14227File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 14228 1422912.5.4 Logical Operators 14230------------------------ 14231 14232Except when they appear in the condition operand of a `GIMPLE_COND', 14233logical `and' and `or' operators are simplified as follows: `a = b && 14234c' becomes 14235 14236 T1 = (bool)b; 14237 if (T1 == true) 14238 T1 = (bool)c; 14239 a = T1; 14240 14241 Note that `T1' in this example cannot be an expression temporary, 14242because it has two different assignments. 14243 1424412.5.5 Manipulating operands 14245---------------------------- 14246 14247All gimple operands are of type `tree'. But only certain types of 14248trees are allowed to be used as operand tuples. Basic validation is 14249controlled by the function `get_gimple_rhs_class', which given a tree 14250code, returns an `enum' with the following values of type `enum 14251gimple_rhs_class' 14252 14253 * `GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 14254 14255 * `GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 14256 14257 * `GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 14258 14259 * `GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 14260 14261 * `GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 14262 split into simpler operands (for instance, `SSA_NAME', `VAR_DECL', 14263 `COMPONENT_REF', etc). 14264 14265 This operand class also acts as an escape hatch for tree nodes 14266 that may be flattened out into the operand vector, but would need 14267 more than two slots on the RHS. For instance, a `COND_EXPR' 14268 expression of the form `(a op b) ? x : y' could be flattened out 14269 on the operand vector using 4 slots, but it would also require 14270 additional processing to distinguish `c = a op b' from `c = a op b 14271 ? x : y'. Something similar occurs with `ASSERT_EXPR'. In time, 14272 these special case tree expressions should be flattened into the 14273 operand vector. 14274 14275 For tree nodes in the categories `GIMPLE_TERNARY_RHS', 14276`GIMPLE_BINARY_RHS' and `GIMPLE_UNARY_RHS', they cannot be stored 14277inside tuples directly. They first need to be flattened and separated 14278into individual components. For instance, given the GENERIC expression 14279 14280 a = b + c 14281 14282 its tree representation is: 14283 14284 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 14285 14286 In this case, the GIMPLE form for this statement is logically 14287identical to its GENERIC form but in GIMPLE, the `PLUS_EXPR' on the RHS 14288of the assignment is not represented as a tree, instead the two 14289operands are taken out of the `PLUS_EXPR' sub-tree and flattened into 14290the GIMPLE tuple as follows: 14291 14292 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 14293 1429412.5.6 Operand vector allocation 14295-------------------------------- 14296 14297The operand vector is stored at the bottom of the three tuple 14298structures that accept operands. This means, that depending on the code 14299of a given statement, its operand vector will be at different offsets 14300from the base of the structure. To access tuple operands use the 14301following accessors 14302 14303 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 14304 Returns the number of operands in statement G. 14305 14306 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 14307 Returns operand `I' from statement `G'. 14308 14309 -- GIMPLE function: tree * gimple_ops (gimple g) 14310 Returns a pointer into the operand vector for statement `G'. This 14311 is computed using an internal table called `gimple_ops_offset_'[]. 14312 This table is indexed by the gimple code of `G'. 14313 14314 When the compiler is built, this table is filled-in using the 14315 sizes of the structures used by each statement code defined in 14316 gimple.def. Since the operand vector is at the bottom of the 14317 structure, for a gimple code `C' the offset is computed as sizeof 14318 (struct-of `C') - sizeof (tree). 14319 14320 This mechanism adds one memory indirection to every access when 14321 using `gimple_op'(), if this becomes a bottleneck, a pass can 14322 choose to memoize the result from `gimple_ops'() and use that to 14323 access the operands. 14324 1432512.5.7 Operand validation 14326------------------------- 14327 14328When adding a new operand to a gimple statement, the operand will be 14329validated according to what each tuple accepts in its operand vector. 14330These predicates are called by the `gimple_NAME_set_...()'. Each tuple 14331will use one of the following predicates (Note, this list is not 14332exhaustive): 14333 14334 -- GIMPLE function: bool is_gimple_val (tree t) 14335 Returns true if t is a "GIMPLE value", which are all the 14336 non-addressable stack variables (variables for which 14337 `is_gimple_reg' returns true) and constants (expressions for which 14338 `is_gimple_min_invariant' returns true). 14339 14340 -- GIMPLE function: bool is_gimple_addressable (tree t) 14341 Returns true if t is a symbol or memory reference whose address 14342 can be taken. 14343 14344 -- GIMPLE function: bool is_gimple_asm_val (tree t) 14345 Similar to `is_gimple_val' but it also accepts hard registers. 14346 14347 -- GIMPLE function: bool is_gimple_call_addr (tree t) 14348 Return true if t is a valid expression to use as the function 14349 called by a `GIMPLE_CALL'. 14350 14351 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 14352 Return true if t is a valid expression to use as first operand of 14353 a `MEM_REF' expression. 14354 14355 -- GIMPLE function: bool is_gimple_constant (tree t) 14356 Return true if t is a valid gimple constant. 14357 14358 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 14359 Return true if t is a valid minimal invariant. This is different 14360 from constants, in that the specific value of t may not be known 14361 at compile time, but it is known that it doesn't change (e.g., the 14362 address of a function local variable). 14363 14364 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 14365 Return true if t is an interprocedural invariant. This means that 14366 t is a valid invariant in all functions (e.g. it can be an address 14367 of a global variable but not of a local one). 14368 14369 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 14370 Return true if t is an `ADDR_EXPR' that does not change once the 14371 program is running (and which is valid in all functions). 14372 1437312.5.8 Statement validation 14374--------------------------- 14375 14376 -- GIMPLE function: bool is_gimple_assign (gimple g) 14377 Return true if the code of g is `GIMPLE_ASSIGN'. 14378 14379 -- GIMPLE function: bool is_gimple_call (gimple g) 14380 Return true if the code of g is `GIMPLE_CALL'. 14381 14382 -- GIMPLE function: bool is_gimple_debug (gimple g) 14383 Return true if the code of g is `GIMPLE_DEBUG'. 14384 14385 -- GIMPLE function: bool gimple_assign_cast_p (gimple g) 14386 Return true if g is a `GIMPLE_ASSIGN' that performs a type cast 14387 operation. 14388 14389 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 14390 Return true if g is a `GIMPLE_DEBUG' that binds the value of an 14391 expression to a variable. 14392 14393 14394File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 14395 1439612.6 Manipulating GIMPLE statements 14397=================================== 14398 14399This section documents all the functions available to handle each of 14400the GIMPLE instructions. 14401 1440212.6.1 Common accessors 14403----------------------- 14404 14405The following are common accessors for gimple statements. 14406 14407 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 14408 Return the code for statement `G'. 14409 14410 -- GIMPLE function: basic_block gimple_bb (gimple g) 14411 Return the basic block to which statement `G' belongs to. 14412 14413 -- GIMPLE function: tree gimple_block (gimple g) 14414 Return the lexical scope block holding statement `G'. 14415 14416 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 14417 Return the type of the main expression computed by `STMT'. Return 14418 `void_type_node' if `STMT' computes nothing. This will only return 14419 something meaningful for `GIMPLE_ASSIGN', `GIMPLE_COND' and 14420 `GIMPLE_CALL'. For all other tuple codes, it will return 14421 `void_type_node'. 14422 14423 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 14424 Return the tree code for the expression computed by `STMT'. This 14425 is only meaningful for `GIMPLE_CALL', `GIMPLE_ASSIGN' and 14426 `GIMPLE_COND'. If `STMT' is `GIMPLE_CALL', it will return 14427 `CALL_EXPR'. For `GIMPLE_COND', it returns the code of the 14428 comparison predicate. For `GIMPLE_ASSIGN' it returns the code of 14429 the operation performed by the `RHS' of the assignment. 14430 14431 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 14432 Set the lexical scope block of `G' to `BLOCK'. 14433 14434 -- GIMPLE function: location_t gimple_locus (gimple g) 14435 Return locus information for statement `G'. 14436 14437 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 14438 Set locus information for statement `G'. 14439 14440 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 14441 Return true if `G' does not have locus information. 14442 14443 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 14444 Return true if no warnings should be emitted for statement `STMT'. 14445 14446 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 14447 visited_p) 14448 Set the visited status on statement `STMT' to `VISITED_P'. 14449 14450 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 14451 Return the visited status on statement `STMT'. 14452 14453 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 14454 plf, bool val_p) 14455 Set pass local flag `PLF' on statement `STMT' to `VAL_P'. 14456 14457 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum 14458 plf_mask plf) 14459 Return the value of pass local flag `PLF' on statement `STMT'. 14460 14461 -- GIMPLE function: bool gimple_has_ops (gimple g) 14462 Return true if statement `G' has register or memory operands. 14463 14464 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 14465 Return true if statement `G' has memory operands. 14466 14467 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 14468 Return the number of operands for statement `G'. 14469 14470 -- GIMPLE function: tree * gimple_ops (gimple g) 14471 Return the array of operands for statement `G'. 14472 14473 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 14474 Return operand `I' for statement `G'. 14475 14476 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 14477 Return a pointer to operand `I' for statement `G'. 14478 14479 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 14480 Set operand `I' of statement `G' to `OP'. 14481 14482 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 14483 Return the set of symbols that have had their address taken by 14484 `STMT'. 14485 14486 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 14487 Return the set of `DEF' operands for statement `G'. 14488 14489 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 14490 def_optype_d *def) 14491 Set `DEF' to be the set of `DEF' operands for statement `G'. 14492 14493 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 14494 Return the set of `USE' operands for statement `G'. 14495 14496 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 14497 use_optype_d *use) 14498 Set `USE' to be the set of `USE' operands for statement `G'. 14499 14500 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 14501 Return the set of `VUSE' operands for statement `G'. 14502 14503 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 14504 voptype_d *ops) 14505 Set `OPS' to be the set of `VUSE' operands for statement `G'. 14506 14507 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 14508 Return the set of `VDEF' operands for statement `G'. 14509 14510 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 14511 voptype_d *ops) 14512 Set `OPS' to be the set of `VDEF' operands for statement `G'. 14513 14514 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 14515 Return the set of symbols loaded by statement `G'. Each element of 14516 the set is the `DECL_UID' of the corresponding symbol. 14517 14518 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 14519 Return the set of symbols stored by statement `G'. Each element of 14520 the set is the `DECL_UID' of the corresponding symbol. 14521 14522 -- GIMPLE function: bool gimple_modified_p (gimple g) 14523 Return true if statement `G' has operands and the modified field 14524 has been set. 14525 14526 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 14527 Return true if statement `STMT' contains volatile operands. 14528 14529 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, 14530 bool volatilep) 14531 Return true if statement `STMT' contains volatile operands. 14532 14533 -- GIMPLE function: void update_stmt (gimple s) 14534 Mark statement `S' as modified, and update it. 14535 14536 -- GIMPLE function: void update_stmt_if_modified (gimple s) 14537 Update statement `S' if it has been marked modified. 14538 14539 -- GIMPLE function: gimple gimple_copy (gimple stmt) 14540 Return a deep copy of statement `STMT'. 14541 14542 14543File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 14544 1454512.7 Tuple specific accessors 14546============================= 14547 14548* Menu: 14549 14550* `GIMPLE_ASM':: 14551* `GIMPLE_ASSIGN':: 14552* `GIMPLE_BIND':: 14553* `GIMPLE_CALL':: 14554* `GIMPLE_CATCH':: 14555* `GIMPLE_COND':: 14556* `GIMPLE_DEBUG':: 14557* `GIMPLE_EH_FILTER':: 14558* `GIMPLE_LABEL':: 14559* `GIMPLE_NOP':: 14560* `GIMPLE_OMP_ATOMIC_LOAD':: 14561* `GIMPLE_OMP_ATOMIC_STORE':: 14562* `GIMPLE_OMP_CONTINUE':: 14563* `GIMPLE_OMP_CRITICAL':: 14564* `GIMPLE_OMP_FOR':: 14565* `GIMPLE_OMP_MASTER':: 14566* `GIMPLE_OMP_ORDERED':: 14567* `GIMPLE_OMP_PARALLEL':: 14568* `GIMPLE_OMP_RETURN':: 14569* `GIMPLE_OMP_SECTION':: 14570* `GIMPLE_OMP_SECTIONS':: 14571* `GIMPLE_OMP_SINGLE':: 14572* `GIMPLE_PHI':: 14573* `GIMPLE_RESX':: 14574* `GIMPLE_RETURN':: 14575* `GIMPLE_SWITCH':: 14576* `GIMPLE_TRY':: 14577* `GIMPLE_WITH_CLEANUP_EXPR':: 14578 14579 14580File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14581 1458212.7.1 `GIMPLE_ASM' 14583------------------- 14584 14585 -- GIMPLE function: gimple gimple_build_asm (const char *string, 14586 ninputs, noutputs, nclobbers, ...) 14587 Build a `GIMPLE_ASM' statement. This statement is used for 14588 building in-line assembly constructs. `STRING' is the assembly 14589 code. `NINPUT' is the number of register inputs. `NOUTPUT' is the 14590 number of register outputs. `NCLOBBERS' is the number of clobbered 14591 registers. The rest of the arguments trees for each input, 14592 output, and clobbered registers. 14593 14594 -- GIMPLE function: gimple gimple_build_asm_vec (const char *, 14595 VEC(tree,gc) *, VEC(tree,gc) *, VEC(tree,gc) *) 14596 Identical to gimple_build_asm, but the arguments are passed in 14597 VECs. 14598 14599 -- GIMPLE function: unsigned gimple_asm_ninputs (gimple g) 14600 Return the number of input operands for `GIMPLE_ASM' `G'. 14601 14602 -- GIMPLE function: unsigned gimple_asm_noutputs (gimple g) 14603 Return the number of output operands for `GIMPLE_ASM' `G'. 14604 14605 -- GIMPLE function: unsigned gimple_asm_nclobbers (gimple g) 14606 Return the number of clobber operands for `GIMPLE_ASM' `G'. 14607 14608 -- GIMPLE function: tree gimple_asm_input_op (gimple g, unsigned index) 14609 Return input operand `INDEX' of `GIMPLE_ASM' `G'. 14610 14611 -- GIMPLE function: void gimple_asm_set_input_op (gimple g, unsigned 14612 index, tree in_op) 14613 Set `IN_OP' to be input operand `INDEX' in `GIMPLE_ASM' `G'. 14614 14615 -- GIMPLE function: tree gimple_asm_output_op (gimple g, unsigned 14616 index) 14617 Return output operand `INDEX' of `GIMPLE_ASM' `G'. 14618 14619 -- GIMPLE function: void gimple_asm_set_output_op (gimple g, unsigned 14620 index, tree out_op) 14621 Set `OUT_OP' to be output operand `INDEX' in `GIMPLE_ASM' `G'. 14622 14623 -- GIMPLE function: tree gimple_asm_clobber_op (gimple g, unsigned 14624 index) 14625 Return clobber operand `INDEX' of `GIMPLE_ASM' `G'. 14626 14627 -- GIMPLE function: void gimple_asm_set_clobber_op (gimple g, unsigned 14628 index, tree clobber_op) 14629 Set `CLOBBER_OP' to be clobber operand `INDEX' in `GIMPLE_ASM' `G'. 14630 14631 -- GIMPLE function: const char * gimple_asm_string (gimple g) 14632 Return the string representing the assembly instruction in 14633 `GIMPLE_ASM' `G'. 14634 14635 -- GIMPLE function: bool gimple_asm_volatile_p (gimple g) 14636 Return true if `G' is an asm statement marked volatile. 14637 14638 -- GIMPLE function: void gimple_asm_set_volatile (gimple g) 14639 Mark asm statement `G' as volatile. 14640 14641 -- GIMPLE function: void gimple_asm_clear_volatile (gimple g) 14642 Remove volatile marker from asm statement `G'. 14643 14644 14645File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors 14646 1464712.7.2 `GIMPLE_ASSIGN' 14648---------------------- 14649 14650 -- GIMPLE function: gimple gimple_build_assign (tree lhs, tree rhs) 14651 Build a `GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 14652 passed in lhs. The right-hand side can be either a unary or 14653 binary tree expression. The expression tree rhs will be flattened 14654 and its operands assigned to the corresponding operand slots in 14655 the new statement. This function is useful when you already have 14656 a tree expression that you want to convert into a tuple. However, 14657 try to avoid building expression trees for the sole purpose of 14658 calling this function. If you already have the operands in 14659 separate trees, it is better to use `gimple_build_assign_with_ops'. 14660 14661 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 14662 gimple_seq *seq_p) 14663 Build a new `GIMPLE_ASSIGN' tuple and append it to the end of 14664 `*SEQ_P'. 14665 14666 `DST'/`SRC' are the destination and source respectively. You can pass 14667ungimplified trees in `DST' or `SRC', in which case they will be 14668converted to a gimple operand if necessary. 14669 14670 This function returns the newly created `GIMPLE_ASSIGN' tuple. 14671 14672 -- GIMPLE function: gimple gimple_build_assign_with_ops (enum 14673 tree_code subcode, tree lhs, tree op1, tree op2) 14674 This function is similar to `gimple_build_assign', but is used to 14675 build a `GIMPLE_ASSIGN' statement when the operands of the 14676 right-hand side of the assignment are already split into different 14677 operands. 14678 14679 The left-hand side is an lvalue passed in lhs. Subcode is the 14680 `tree_code' for the right-hand side of the assignment. Op1 and op2 14681 are the operands. If op2 is null, subcode must be a `tree_code' 14682 for a unary expression. 14683 14684 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 14685 Return the code of the expression computed on the `RHS' of 14686 assignment statement `G'. 14687 14688 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 14689 (gimple g) 14690 Return the gimple rhs class of the code for the expression 14691 computed on the rhs of assignment statement `G'. This will never 14692 return `GIMPLE_INVALID_RHS'. 14693 14694 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 14695 Return the `LHS' of assignment statement `G'. 14696 14697 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 14698 Return a pointer to the `LHS' of assignment statement `G'. 14699 14700 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 14701 Return the first operand on the `RHS' of assignment statement `G'. 14702 14703 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 14704 Return the address of the first operand on the `RHS' of assignment 14705 statement `G'. 14706 14707 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 14708 Return the second operand on the `RHS' of assignment statement `G'. 14709 14710 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 14711 Return the address of the second operand on the `RHS' of assignment 14712 statement `G'. 14713 14714 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 14715 Return the third operand on the `RHS' of assignment statement `G'. 14716 14717 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 14718 Return the address of the third operand on the `RHS' of assignment 14719 statement `G'. 14720 14721 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 14722 Set `LHS' to be the `LHS' operand of assignment statement `G'. 14723 14724 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 14725 Set `RHS' to be the first operand on the `RHS' of assignment 14726 statement `G'. 14727 14728 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 14729 Set `RHS' to be the second operand on the `RHS' of assignment 14730 statement `G'. 14731 14732 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 14733 Set `RHS' to be the third operand on the `RHS' of assignment 14734 statement `G'. 14735 14736 -- GIMPLE function: bool gimple_assign_cast_p (gimple s) 14737 Return true if `S' is a type-cast assignment. 14738 14739 14740File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors 14741 1474212.7.3 `GIMPLE_BIND' 14743-------------------- 14744 14745 -- GIMPLE function: gimple gimple_build_bind (tree vars, gimple_seq 14746 body) 14747 Build a `GIMPLE_BIND' statement with a list of variables in `VARS' 14748 and a body of statements in sequence `BODY'. 14749 14750 -- GIMPLE function: tree gimple_bind_vars (gimple g) 14751 Return the variables declared in the `GIMPLE_BIND' statement `G'. 14752 14753 -- GIMPLE function: void gimple_bind_set_vars (gimple g, tree vars) 14754 Set `VARS' to be the set of variables declared in the `GIMPLE_BIND' 14755 statement `G'. 14756 14757 -- GIMPLE function: void gimple_bind_append_vars (gimple g, tree vars) 14758 Append `VARS' to the set of variables declared in the `GIMPLE_BIND' 14759 statement `G'. 14760 14761 -- GIMPLE function: gimple_seq gimple_bind_body (gimple g) 14762 Return the GIMPLE sequence contained in the `GIMPLE_BIND' statement 14763 `G'. 14764 14765 -- GIMPLE function: void gimple_bind_set_body (gimple g, gimple_seq 14766 seq) 14767 Set `SEQ' to be sequence contained in the `GIMPLE_BIND' statement 14768 `G'. 14769 14770 -- GIMPLE function: void gimple_bind_add_stmt (gimple gs, gimple stmt) 14771 Append a statement to the end of a `GIMPLE_BIND''s body. 14772 14773 -- GIMPLE function: void gimple_bind_add_seq (gimple gs, gimple_seq 14774 seq) 14775 Append a sequence of statements to the end of a `GIMPLE_BIND''s 14776 body. 14777 14778 -- GIMPLE function: tree gimple_bind_block (gimple g) 14779 Return the `TREE_BLOCK' node associated with `GIMPLE_BIND' 14780 statement `G'. This is analogous to the `BIND_EXPR_BLOCK' field in 14781 trees. 14782 14783 -- GIMPLE function: void gimple_bind_set_block (gimple g, tree block) 14784 Set `BLOCK' to be the `TREE_BLOCK' node associated with 14785 `GIMPLE_BIND' statement `G'. 14786 14787 14788File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors 14789 1479012.7.4 `GIMPLE_CALL' 14791-------------------- 14792 14793 -- GIMPLE function: gimple gimple_build_call (tree fn, unsigned nargs, 14794 ...) 14795 Build a `GIMPLE_CALL' statement to function `FN'. The argument 14796 `FN' must be either a `FUNCTION_DECL' or a gimple call address as 14797 determined by `is_gimple_call_addr'. `NARGS' are the number of 14798 arguments. The rest of the arguments follow the argument `NARGS', 14799 and must be trees that are valid as rvalues in gimple (i.e., each 14800 operand is validated with `is_gimple_operand'). 14801 14802 -- GIMPLE function: gimple gimple_build_call_from_tree (tree call_expr) 14803 Build a `GIMPLE_CALL' from a `CALL_EXPR' node. The arguments and 14804 the function are taken from the expression directly. This routine 14805 assumes that `call_expr' is already in GIMPLE form. That is, its 14806 operands are GIMPLE values and the function call needs no further 14807 simplification. All the call flags in `call_expr' are copied over 14808 to the new `GIMPLE_CALL'. 14809 14810 -- GIMPLE function: gimple gimple_build_call_vec (tree fn, `VEC'(tree, 14811 heap) *args) 14812 Identical to `gimple_build_call' but the arguments are stored in a 14813 `VEC'(). 14814 14815 -- GIMPLE function: tree gimple_call_lhs (gimple g) 14816 Return the `LHS' of call statement `G'. 14817 14818 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 14819 Return a pointer to the `LHS' of call statement `G'. 14820 14821 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 14822 Set `LHS' to be the `LHS' operand of call statement `G'. 14823 14824 -- GIMPLE function: tree gimple_call_fn (gimple g) 14825 Return the tree node representing the function called by call 14826 statement `G'. 14827 14828 -- GIMPLE function: void gimple_call_set_fn (gimple g, tree fn) 14829 Set `FN' to be the function called by call statement `G'. This has 14830 to be a gimple value specifying the address of the called function. 14831 14832 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 14833 If a given `GIMPLE_CALL''s callee is a `FUNCTION_DECL', return it. 14834 Otherwise return `NULL'. This function is analogous to 14835 `get_callee_fndecl' in `GENERIC'. 14836 14837 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 14838 Set the called function to `FNDECL'. 14839 14840 -- GIMPLE function: tree gimple_call_return_type (gimple g) 14841 Return the type returned by call statement `G'. 14842 14843 -- GIMPLE function: tree gimple_call_chain (gimple g) 14844 Return the static chain for call statement `G'. 14845 14846 -- GIMPLE function: void gimple_call_set_chain (gimple g, tree chain) 14847 Set `CHAIN' to be the static chain for call statement `G'. 14848 14849 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 14850 Return the number of arguments used by call statement `G'. 14851 14852 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 14853 Return the argument at position `INDEX' for call statement `G'. 14854 The first argument is 0. 14855 14856 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 14857 index) 14858 Return a pointer to the argument at position `INDEX' for call 14859 statement `G'. 14860 14861 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned 14862 index, tree arg) 14863 Set `ARG' to be the argument at position `INDEX' for call statement 14864 `G'. 14865 14866 -- GIMPLE function: void gimple_call_set_tail (gimple s) 14867 Mark call statement `S' as being a tail call (i.e., a call just 14868 before the exit of a function). These calls are candidate for tail 14869 call optimization. 14870 14871 -- GIMPLE function: bool gimple_call_tail_p (gimple s) 14872 Return true if `GIMPLE_CALL' `S' is marked as a tail call. 14873 14874 -- GIMPLE function: void gimple_call_mark_uninlinable (gimple s) 14875 Mark `GIMPLE_CALL' `S' as being uninlinable. 14876 14877 -- GIMPLE function: bool gimple_call_cannot_inline_p (gimple s) 14878 Return true if `GIMPLE_CALL' `S' cannot be inlined. 14879 14880 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 14881 Return true if `S' is a noreturn call. 14882 14883 -- GIMPLE function: gimple gimple_call_copy_skip_args (gimple stmt, 14884 bitmap args_to_skip) 14885 Build a `GIMPLE_CALL' identical to `STMT' but skipping the 14886 arguments in the positions marked by the set `ARGS_TO_SKIP'. 14887 14888 14889File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_COND', Prev: `GIMPLE_CALL', Up: Tuple specific accessors 14890 1489112.7.5 `GIMPLE_CATCH' 14892--------------------- 14893 14894 -- GIMPLE function: gimple gimple_build_catch (tree types, gimple_seq 14895 handler) 14896 Build a `GIMPLE_CATCH' statement. `TYPES' are the tree types this 14897 catch handles. `HANDLER' is a sequence of statements with the code 14898 for the handler. 14899 14900 -- GIMPLE function: tree gimple_catch_types (gimple g) 14901 Return the types handled by `GIMPLE_CATCH' statement `G'. 14902 14903 -- GIMPLE function: tree * gimple_catch_types_ptr (gimple g) 14904 Return a pointer to the types handled by `GIMPLE_CATCH' statement 14905 `G'. 14906 14907 -- GIMPLE function: gimple_seq gimple_catch_handler (gimple g) 14908 Return the GIMPLE sequence representing the body of the handler of 14909 `GIMPLE_CATCH' statement `G'. 14910 14911 -- GIMPLE function: void gimple_catch_set_types (gimple g, tree t) 14912 Set `T' to be the set of types handled by `GIMPLE_CATCH' `G'. 14913 14914 -- GIMPLE function: void gimple_catch_set_handler (gimple g, 14915 gimple_seq handler) 14916 Set `HANDLER' to be the body of `GIMPLE_CATCH' `G'. 14917 14918 14919File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_DEBUG', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors 14920 1492112.7.6 `GIMPLE_COND' 14922-------------------- 14923 14924 -- GIMPLE function: gimple gimple_build_cond (enum tree_code 14925 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 14926 Build a `GIMPLE_COND' statement. `A' `GIMPLE_COND' statement 14927 compares `LHS' and `RHS' and if the condition in `PRED_CODE' is 14928 true, jump to the label in `t_label', otherwise jump to the label 14929 in `f_label'. `PRED_CODE' are relational operator tree codes like 14930 `EQ_EXPR', `LT_EXPR', `LE_EXPR', `NE_EXPR', etc. 14931 14932 -- GIMPLE function: gimple gimple_build_cond_from_tree (tree cond, 14933 tree t_label, tree f_label) 14934 Build a `GIMPLE_COND' statement from the conditional expression 14935 tree `COND'. `T_LABEL' and `F_LABEL' are as in 14936 `gimple_build_cond'. 14937 14938 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 14939 Return the code of the predicate computed by conditional statement 14940 `G'. 14941 14942 -- GIMPLE function: void gimple_cond_set_code (gimple g, enum 14943 tree_code code) 14944 Set `CODE' to be the predicate code for the conditional statement 14945 `G'. 14946 14947 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 14948 Return the `LHS' of the predicate computed by conditional statement 14949 `G'. 14950 14951 -- GIMPLE function: void gimple_cond_set_lhs (gimple g, tree lhs) 14952 Set `LHS' to be the `LHS' operand of the predicate computed by 14953 conditional statement `G'. 14954 14955 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 14956 Return the `RHS' operand of the predicate computed by conditional 14957 `G'. 14958 14959 -- GIMPLE function: void gimple_cond_set_rhs (gimple g, tree rhs) 14960 Set `RHS' to be the `RHS' operand of the predicate computed by 14961 conditional statement `G'. 14962 14963 -- GIMPLE function: tree gimple_cond_true_label (gimple g) 14964 Return the label used by conditional statement `G' when its 14965 predicate evaluates to true. 14966 14967 -- GIMPLE function: void gimple_cond_set_true_label (gimple g, tree 14968 label) 14969 Set `LABEL' to be the label used by conditional statement `G' when 14970 its predicate evaluates to true. 14971 14972 -- GIMPLE function: void gimple_cond_set_false_label (gimple g, tree 14973 label) 14974 Set `LABEL' to be the label used by conditional statement `G' when 14975 its predicate evaluates to false. 14976 14977 -- GIMPLE function: tree gimple_cond_false_label (gimple g) 14978 Return the label used by conditional statement `G' when its 14979 predicate evaluates to false. 14980 14981 -- GIMPLE function: void gimple_cond_make_false (gimple g) 14982 Set the conditional `COND_STMT' to be of the form 'if (1 == 0)'. 14983 14984 -- GIMPLE function: void gimple_cond_make_true (gimple g) 14985 Set the conditional `COND_STMT' to be of the form 'if (1 == 1)'. 14986 14987 14988File: gccint.info, Node: `GIMPLE_DEBUG', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_COND', Up: Tuple specific accessors 14989 1499012.7.7 `GIMPLE_DEBUG' 14991--------------------- 14992 14993 -- GIMPLE function: gimple gimple_build_debug_bind (tree var, tree 14994 value, gimple stmt) 14995 Build a `GIMPLE_DEBUG' statement with `GIMPLE_DEBUG_BIND' of 14996 `subcode'. The effect of this statement is to tell debug 14997 information generation machinery that the value of user variable 14998 `var' is given by `value' at that point, and to remain with that 14999 value until `var' runs out of scope, a dynamically-subsequent 15000 debug bind statement overrides the binding, or conflicting values 15001 reach a control flow merge point. Even if components of the 15002 `value' expression change afterwards, the variable is supposed to 15003 retain the same value, though not necessarily the same location. 15004 15005 It is expected that `var' be most often a tree for automatic user 15006 variables (`VAR_DECL' or `PARM_DECL') that satisfy the 15007 requirements for gimple registers, but it may also be a tree for a 15008 scalarized component of a user variable (`ARRAY_REF', 15009 `COMPONENT_REF'), or a debug temporary (`DEBUG_EXPR_DECL'). 15010 15011 As for `value', it can be an arbitrary tree expression, but it is 15012 recommended that it be in a suitable form for a gimple assignment 15013 `RHS'. It is not expected that user variables that could appear 15014 as `var' ever appear in `value', because in the latter we'd have 15015 their `SSA_NAME's instead, but even if they were not in SSA form, 15016 user variables appearing in `value' are to be regarded as part of 15017 the executable code space, whereas those in `var' are to be 15018 regarded as part of the source code space. There is no way to 15019 refer to the value bound to a user variable within a `value' 15020 expression. 15021 15022 If `value' is `GIMPLE_DEBUG_BIND_NOVALUE', debug information 15023 generation machinery is informed that the variable `var' is 15024 unbound, i.e., that its value is indeterminate, which sometimes 15025 means it is really unavailable, and other times that the compiler 15026 could not keep track of it. 15027 15028 Block and location information for the newly-created stmt are 15029 taken from `stmt', if given. 15030 15031 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 15032 Return the user variable VAR that is bound at `stmt'. 15033 15034 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 15035 Return the value expression that is bound to a user variable at 15036 `stmt'. 15037 15038 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 15039 stmt) 15040 Return a pointer to the value expression that is bound to a user 15041 variable at `stmt'. 15042 15043 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 15044 var) 15045 Modify the user variable bound at `stmt' to VAR. 15046 15047 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, 15048 tree var) 15049 Modify the value bound to the user variable bound at `stmt' to 15050 VALUE. 15051 15052 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 15053 Modify the value bound to the user variable bound at `stmt' so 15054 that the variable becomes unbound. 15055 15056 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 15057 Return `TRUE' if `stmt' binds a user variable to a value, and 15058 `FALSE' if it unbinds the variable. 15059 15060 15061File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_DEBUG', Up: Tuple specific accessors 15062 1506312.7.8 `GIMPLE_EH_FILTER' 15064------------------------- 15065 15066 -- GIMPLE function: gimple gimple_build_eh_filter (tree types, 15067 gimple_seq failure) 15068 Build a `GIMPLE_EH_FILTER' statement. `TYPES' are the filter's 15069 types. `FAILURE' is a sequence with the filter's failure action. 15070 15071 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 15072 Return the types handled by `GIMPLE_EH_FILTER' statement `G'. 15073 15074 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 15075 Return a pointer to the types handled by `GIMPLE_EH_FILTER' 15076 statement `G'. 15077 15078 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 15079 Return the sequence of statement to execute when `GIMPLE_EH_FILTER' 15080 statement fails. 15081 15082 -- GIMPLE function: void gimple_eh_filter_set_types (gimple g, tree 15083 types) 15084 Set `TYPES' to be the set of types handled by `GIMPLE_EH_FILTER' 15085 `G'. 15086 15087 -- GIMPLE function: void gimple_eh_filter_set_failure (gimple g, 15088 gimple_seq failure) 15089 Set `FAILURE' to be the sequence of statements to execute on 15090 failure for `GIMPLE_EH_FILTER' `G'. 15091 15092 -- GIMPLE function: bool gimple_eh_filter_must_not_throw (gimple g) 15093 Return the `EH_FILTER_MUST_NOT_THROW' flag. 15094 15095 -- GIMPLE function: void gimple_eh_filter_set_must_not_throw (gimple 15096 g, bool mntp) 15097 Set the `EH_FILTER_MUST_NOT_THROW' flag. 15098 15099 15100File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_NOP', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors 15101 1510212.7.9 `GIMPLE_LABEL' 15103--------------------- 15104 15105 -- GIMPLE function: gimple gimple_build_label (tree label) 15106 Build a `GIMPLE_LABEL' statement with corresponding to the tree 15107 label, `LABEL'. 15108 15109 -- GIMPLE function: tree gimple_label_label (gimple g) 15110 Return the `LABEL_DECL' node used by `GIMPLE_LABEL' statement `G'. 15111 15112 -- GIMPLE function: void gimple_label_set_label (gimple g, tree label) 15113 Set `LABEL' to be the `LABEL_DECL' node used by `GIMPLE_LABEL' 15114 statement `G'. 15115 15116 -- GIMPLE function: gimple gimple_build_goto (tree dest) 15117 Build a `GIMPLE_GOTO' statement to label `DEST'. 15118 15119 -- GIMPLE function: tree gimple_goto_dest (gimple g) 15120 Return the destination of the unconditional jump `G'. 15121 15122 -- GIMPLE function: void gimple_goto_set_dest (gimple g, tree dest) 15123 Set `DEST' to be the destination of the unconditional jump `G'. 15124 15125 15126File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors 15127 1512812.7.10 `GIMPLE_NOP' 15129-------------------- 15130 15131 -- GIMPLE function: gimple gimple_build_nop (void) 15132 Build a `GIMPLE_NOP' statement. 15133 15134 -- GIMPLE function: bool gimple_nop_p (gimple g) 15135 Returns `TRUE' if statement `G' is a `GIMPLE_NOP'. 15136 15137 15138File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors 15139 1514012.7.11 `GIMPLE_OMP_ATOMIC_LOAD' 15141-------------------------------- 15142 15143 -- GIMPLE function: gimple gimple_build_omp_atomic_load (tree lhs, 15144 tree rhs) 15145 Build a `GIMPLE_OMP_ATOMIC_LOAD' statement. `LHS' is the left-hand 15146 side of the assignment. `RHS' is the right-hand side of the 15147 assignment. 15148 15149 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (gimple g, 15150 tree lhs) 15151 Set the `LHS' of an atomic load. 15152 15153 -- GIMPLE function: tree gimple_omp_atomic_load_lhs (gimple g) 15154 Get the `LHS' of an atomic load. 15155 15156 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (gimple g, 15157 tree rhs) 15158 Set the `RHS' of an atomic set. 15159 15160 -- GIMPLE function: tree gimple_omp_atomic_load_rhs (gimple g) 15161 Get the `RHS' of an atomic set. 15162 15163 15164File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors 15165 1516612.7.12 `GIMPLE_OMP_ATOMIC_STORE' 15167--------------------------------- 15168 15169 -- GIMPLE function: gimple gimple_build_omp_atomic_store (tree val) 15170 Build a `GIMPLE_OMP_ATOMIC_STORE' statement. `VAL' is the value to 15171 be stored. 15172 15173 -- GIMPLE function: void gimple_omp_atomic_store_set_val (gimple g, 15174 tree val) 15175 Set the value being stored in an atomic store. 15176 15177 -- GIMPLE function: tree gimple_omp_atomic_store_val (gimple g) 15178 Return the value being stored in an atomic store. 15179 15180 15181File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors 15182 1518312.7.13 `GIMPLE_OMP_CONTINUE' 15184----------------------------- 15185 15186 -- GIMPLE function: gimple gimple_build_omp_continue (tree 15187 control_def, tree control_use) 15188 Build a `GIMPLE_OMP_CONTINUE' statement. `CONTROL_DEF' is the 15189 definition of the control variable. `CONTROL_USE' is the use of 15190 the control variable. 15191 15192 -- GIMPLE function: tree gimple_omp_continue_control_def (gimple s) 15193 Return the definition of the control variable on a 15194 `GIMPLE_OMP_CONTINUE' in `S'. 15195 15196 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (gimple s) 15197 Same as above, but return the pointer. 15198 15199 -- GIMPLE function: tree gimple_omp_continue_set_control_def (gimple s) 15200 Set the control variable definition for a `GIMPLE_OMP_CONTINUE' 15201 statement in `S'. 15202 15203 -- GIMPLE function: tree gimple_omp_continue_control_use (gimple s) 15204 Return the use of the control variable on a `GIMPLE_OMP_CONTINUE' 15205 in `S'. 15206 15207 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (gimple s) 15208 Same as above, but return the pointer. 15209 15210 -- GIMPLE function: tree gimple_omp_continue_set_control_use (gimple s) 15211 Set the control variable use for a `GIMPLE_OMP_CONTINUE' statement 15212 in `S'. 15213 15214 15215File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors 15216 1521712.7.14 `GIMPLE_OMP_CRITICAL' 15218----------------------------- 15219 15220 -- GIMPLE function: gimple gimple_build_omp_critical (gimple_seq body, 15221 tree name) 15222 Build a `GIMPLE_OMP_CRITICAL' statement. `BODY' is the sequence of 15223 statements for which only one thread can execute. `NAME' is an 15224 optional identifier for this critical block. 15225 15226 -- GIMPLE function: tree gimple_omp_critical_name (gimple g) 15227 Return the name associated with `OMP_CRITICAL' statement `G'. 15228 15229 -- GIMPLE function: tree * gimple_omp_critical_name_ptr (gimple g) 15230 Return a pointer to the name associated with `OMP' critical 15231 statement `G'. 15232 15233 -- GIMPLE function: void gimple_omp_critical_set_name (gimple g, tree 15234 name) 15235 Set `NAME' to be the name associated with `OMP' critical statement 15236 `G'. 15237 15238 15239File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors 15240 1524112.7.15 `GIMPLE_OMP_FOR' 15242------------------------ 15243 15244 -- GIMPLE function: gimple gimple_build_omp_for (gimple_seq body, tree 15245 clauses, tree index, tree initial, tree final, tree incr, 15246 gimple_seq pre_body, enum tree_code omp_for_cond) 15247 Build a `GIMPLE_OMP_FOR' statement. `BODY' is sequence of 15248 statements inside the for loop. `CLAUSES', are any of the `OMP' 15249 loop construct's clauses: private, firstprivate, lastprivate, 15250 reductions, ordered, schedule, and nowait. `PRE_BODY' is the 15251 sequence of statements that are loop invariant. `INDEX' is the 15252 index variable. `INITIAL' is the initial value of `INDEX'. 15253 `FINAL' is final value of `INDEX'. OMP_FOR_COND is the predicate 15254 used to compare `INDEX' and `FINAL'. `INCR' is the increment 15255 expression. 15256 15257 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 15258 Return the clauses associated with `OMP_FOR' `G'. 15259 15260 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 15261 Return a pointer to the `OMP_FOR' `G'. 15262 15263 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 15264 clauses) 15265 Set `CLAUSES' to be the list of clauses associated with `OMP_FOR' 15266 `G'. 15267 15268 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 15269 Return the index variable for `OMP_FOR' `G'. 15270 15271 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 15272 Return a pointer to the index variable for `OMP_FOR' `G'. 15273 15274 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 15275 index) 15276 Set `INDEX' to be the index variable for `OMP_FOR' `G'. 15277 15278 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 15279 Return the initial value for `OMP_FOR' `G'. 15280 15281 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 15282 Return a pointer to the initial value for `OMP_FOR' `G'. 15283 15284 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 15285 initial) 15286 Set `INITIAL' to be the initial value for `OMP_FOR' `G'. 15287 15288 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 15289 Return the final value for `OMP_FOR' `G'. 15290 15291 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 15292 turn a pointer to the final value for `OMP_FOR' `G'. 15293 15294 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 15295 final) 15296 Set `FINAL' to be the final value for `OMP_FOR' `G'. 15297 15298 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 15299 Return the increment value for `OMP_FOR' `G'. 15300 15301 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 15302 Return a pointer to the increment value for `OMP_FOR' `G'. 15303 15304 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 15305 Set `INCR' to be the increment value for `OMP_FOR' `G'. 15306 15307 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 15308 Return the sequence of statements to execute before the `OMP_FOR' 15309 statement `G' starts. 15310 15311 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 15312 gimple_seq pre_body) 15313 Set `PRE_BODY' to be the sequence of statements to execute before 15314 the `OMP_FOR' statement `G' starts. 15315 15316 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 15317 tree_code cond) 15318 Set `COND' to be the condition code for `OMP_FOR' `G'. 15319 15320 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 15321 Return the condition code associated with `OMP_FOR' `G'. 15322 15323 15324File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors 15325 1532612.7.16 `GIMPLE_OMP_MASTER' 15327--------------------------- 15328 15329 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 15330 Build a `GIMPLE_OMP_MASTER' statement. `BODY' is the sequence of 15331 statements to be executed by just the master. 15332 15333 15334File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors 15335 1533612.7.17 `GIMPLE_OMP_ORDERED' 15337---------------------------- 15338 15339 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 15340 Build a `GIMPLE_OMP_ORDERED' statement. 15341 15342 `BODY' is the sequence of statements inside a loop that will executed 15343in sequence. 15344 15345 15346File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors 15347 1534812.7.18 `GIMPLE_OMP_PARALLEL' 15349----------------------------- 15350 15351 -- GIMPLE function: gimple gimple_build_omp_parallel (gimple_seq body, 15352 tree clauses, tree child_fn, tree data_arg) 15353 Build a `GIMPLE_OMP_PARALLEL' statement. 15354 15355 `BODY' is sequence of statements which are executed in parallel. 15356`CLAUSES', are the `OMP' parallel construct's clauses. `CHILD_FN' is 15357the function created for the parallel threads to execute. `DATA_ARG' 15358are the shared data argument(s). 15359 15360 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 15361 Return true if `OMP' parallel statement `G' has the 15362 `GF_OMP_PARALLEL_COMBINED' flag set. 15363 15364 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 15365 Set the `GF_OMP_PARALLEL_COMBINED' field in `OMP' parallel 15366 statement `G'. 15367 15368 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 15369 Return the body for the `OMP' statement `G'. 15370 15371 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 15372 body) 15373 Set `BODY' to be the body for the `OMP' statement `G'. 15374 15375 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 15376 Return the clauses associated with `OMP_PARALLEL' `G'. 15377 15378 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr (gimple g) 15379 Return a pointer to the clauses associated with `OMP_PARALLEL' `G'. 15380 15381 -- GIMPLE function: void gimple_omp_parallel_set_clauses (gimple g, 15382 tree clauses) 15383 Set `CLAUSES' to be the list of clauses associated with 15384 `OMP_PARALLEL' `G'. 15385 15386 -- GIMPLE function: tree gimple_omp_parallel_child_fn (gimple g) 15387 Return the child function used to hold the body of `OMP_PARALLEL' 15388 `G'. 15389 15390 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr (gimple g) 15391 Return a pointer to the child function used to hold the body of 15392 `OMP_PARALLEL' `G'. 15393 15394 -- GIMPLE function: void gimple_omp_parallel_set_child_fn (gimple g, 15395 tree child_fn) 15396 Set `CHILD_FN' to be the child function for `OMP_PARALLEL' `G'. 15397 15398 -- GIMPLE function: tree gimple_omp_parallel_data_arg (gimple g) 15399 Return the artificial argument used to send variables and values 15400 from the parent to the children threads in `OMP_PARALLEL' `G'. 15401 15402 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr (gimple g) 15403 Return a pointer to the data argument for `OMP_PARALLEL' `G'. 15404 15405 -- GIMPLE function: void gimple_omp_parallel_set_data_arg (gimple g, 15406 tree data_arg) 15407 Set `DATA_ARG' to be the data argument for `OMP_PARALLEL' `G'. 15408 15409 -- GIMPLE function: bool is_gimple_omp (gimple stmt) 15410 Returns true when the gimple statement `STMT' is any of the OpenMP 15411 types. 15412 15413 15414File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors 15415 1541612.7.19 `GIMPLE_OMP_RETURN' 15417--------------------------- 15418 15419 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 15420 Build a `GIMPLE_OMP_RETURN' statement. `WAIT_P' is true if this is 15421 a non-waiting return. 15422 15423 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 15424 Set the nowait flag on `GIMPLE_OMP_RETURN' statement `S'. 15425 15426 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 15427 Return true if `OMP' return statement `G' has the 15428 `GF_OMP_RETURN_NOWAIT' flag set. 15429 15430 15431File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors 15432 1543312.7.20 `GIMPLE_OMP_SECTION' 15434---------------------------- 15435 15436 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 15437 Build a `GIMPLE_OMP_SECTION' statement for a sections statement. 15438 15439 `BODY' is the sequence of statements in the section. 15440 15441 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 15442 Return true if `OMP' section statement `G' has the 15443 `GF_OMP_SECTION_LAST' flag set. 15444 15445 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 15446 Set the `GF_OMP_SECTION_LAST' flag on `G'. 15447 15448 15449File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors 15450 1545112.7.21 `GIMPLE_OMP_SECTIONS' 15452----------------------------- 15453 15454 -- GIMPLE function: gimple gimple_build_omp_sections (gimple_seq body, 15455 tree clauses) 15456 Build a `GIMPLE_OMP_SECTIONS' statement. `BODY' is a sequence of 15457 section statements. `CLAUSES' are any of the `OMP' sections 15458 construct's clauses: private, firstprivate, lastprivate, 15459 reduction, and nowait. 15460 15461 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 15462 Build a `GIMPLE_OMP_SECTIONS_SWITCH' statement. 15463 15464 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 15465 Return the control variable associated with the 15466 `GIMPLE_OMP_SECTIONS' in `G'. 15467 15468 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 15469 Return a pointer to the clauses associated with the 15470 `GIMPLE_OMP_SECTIONS' in `G'. 15471 15472 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 15473 tree control) 15474 Set `CONTROL' to be the set of clauses associated with the 15475 `GIMPLE_OMP_SECTIONS' in `G'. 15476 15477 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 15478 Return the clauses associated with `OMP_SECTIONS' `G'. 15479 15480 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 15481 Return a pointer to the clauses associated with `OMP_SECTIONS' `G'. 15482 15483 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 15484 tree clauses) 15485 Set `CLAUSES' to be the set of clauses associated with 15486 `OMP_SECTIONS' `G'. 15487 15488 15489File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors 15490 1549112.7.22 `GIMPLE_OMP_SINGLE' 15492--------------------------- 15493 15494 -- GIMPLE function: gimple gimple_build_omp_single (gimple_seq body, 15495 tree clauses) 15496 Build a `GIMPLE_OMP_SINGLE' statement. `BODY' is the sequence of 15497 statements that will be executed once. `CLAUSES' are any of the 15498 `OMP' single construct's clauses: private, firstprivate, 15499 copyprivate, nowait. 15500 15501 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 15502 Return the clauses associated with `OMP_SINGLE' `G'. 15503 15504 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 15505 Return a pointer to the clauses associated with `OMP_SINGLE' `G'. 15506 15507 -- GIMPLE function: void gimple_omp_single_set_clauses (gimple g, tree 15508 clauses) 15509 Set `CLAUSES' to be the clauses associated with `OMP_SINGLE' `G'. 15510 15511 15512File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors 15513 1551412.7.23 `GIMPLE_PHI' 15515-------------------- 15516 15517 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 15518 Return the maximum number of arguments supported by `GIMPLE_PHI' 15519 `G'. 15520 15521 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 15522 Return the number of arguments in `GIMPLE_PHI' `G'. This must 15523 always be exactly the number of incoming edges for the basic block 15524 holding `G'. 15525 15526 -- GIMPLE function: tree gimple_phi_result (gimple g) 15527 Return the `SSA' name created by `GIMPLE_PHI' `G'. 15528 15529 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 15530 Return a pointer to the `SSA' name created by `GIMPLE_PHI' `G'. 15531 15532 -- GIMPLE function: void gimple_phi_set_result (gimple g, tree result) 15533 Set `RESULT' to be the `SSA' name created by `GIMPLE_PHI' `G'. 15534 15535 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 15536 Return the `PHI' argument corresponding to incoming edge `INDEX' 15537 for `GIMPLE_PHI' `G'. 15538 15539 -- GIMPLE function: void gimple_phi_set_arg (gimple g, index, struct 15540 phi_arg_d * phiarg) 15541 Set `PHIARG' to be the argument corresponding to incoming edge 15542 `INDEX' for `GIMPLE_PHI' `G'. 15543 15544 15545File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors 15546 1554712.7.24 `GIMPLE_RESX' 15548--------------------- 15549 15550 -- GIMPLE function: gimple gimple_build_resx (int region) 15551 Build a `GIMPLE_RESX' statement which is a statement. This 15552 statement is a placeholder for _Unwind_Resume before we know if a 15553 function call or a branch is needed. `REGION' is the exception 15554 region from which control is flowing. 15555 15556 -- GIMPLE function: int gimple_resx_region (gimple g) 15557 Return the region number for `GIMPLE_RESX' `G'. 15558 15559 -- GIMPLE function: void gimple_resx_set_region (gimple g, int region) 15560 Set `REGION' to be the region number for `GIMPLE_RESX' `G'. 15561 15562 15563File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors 15564 1556512.7.25 `GIMPLE_RETURN' 15566----------------------- 15567 15568 -- GIMPLE function: gimple gimple_build_return (tree retval) 15569 Build a `GIMPLE_RETURN' statement whose return value is retval. 15570 15571 -- GIMPLE function: tree gimple_return_retval (gimple g) 15572 Return the return value for `GIMPLE_RETURN' `G'. 15573 15574 -- GIMPLE function: void gimple_return_set_retval (gimple g, tree 15575 retval) 15576 Set `RETVAL' to be the return value for `GIMPLE_RETURN' `G'. 15577 15578 15579File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors 15580 1558112.7.26 `GIMPLE_SWITCH' 15582----------------------- 15583 15584 -- GIMPLE function: gimple gimple_build_switch (tree index, tree 15585 default_label, `VEC'(tree,heap) *args) 15586 Build a `GIMPLE_SWITCH' statement. `INDEX' is the index variable 15587 to switch on, and `DEFAULT_LABEL' represents the default label. 15588 `ARGS' is a vector of `CASE_LABEL_EXPR' trees that contain the 15589 non-default case labels. Each label is a tree of code 15590 `CASE_LABEL_EXPR'. 15591 15592 -- GIMPLE function: unsigned gimple_switch_num_labels (gimple g) 15593 Return the number of labels associated with the switch statement 15594 `G'. 15595 15596 -- GIMPLE function: void gimple_switch_set_num_labels (gimple g, 15597 unsigned nlabels) 15598 Set `NLABELS' to be the number of labels for the switch statement 15599 `G'. 15600 15601 -- GIMPLE function: tree gimple_switch_index (gimple g) 15602 Return the index variable used by the switch statement `G'. 15603 15604 -- GIMPLE function: void gimple_switch_set_index (gimple g, tree index) 15605 Set `INDEX' to be the index variable for switch statement `G'. 15606 15607 -- GIMPLE function: tree gimple_switch_label (gimple g, unsigned index) 15608 Return the label numbered `INDEX'. The default label is 0, followed 15609 by any labels in a switch statement. 15610 15611 -- GIMPLE function: void gimple_switch_set_label (gimple g, unsigned 15612 index, tree label) 15613 Set the label number `INDEX' to `LABEL'. 0 is always the default 15614 label. 15615 15616 -- GIMPLE function: tree gimple_switch_default_label (gimple g) 15617 Return the default label for a switch statement. 15618 15619 -- GIMPLE function: void gimple_switch_set_default_label (gimple g, 15620 tree label) 15621 Set the default label for a switch statement. 15622 15623 15624File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors 15625 1562612.7.27 `GIMPLE_TRY' 15627-------------------- 15628 15629 -- GIMPLE function: gimple gimple_build_try (gimple_seq eval, 15630 gimple_seq cleanup, unsigned int kind) 15631 Build a `GIMPLE_TRY' statement. `EVAL' is a sequence with the 15632 expression to evaluate. `CLEANUP' is a sequence of statements to 15633 run at clean-up time. `KIND' is the enumeration value 15634 `GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 15635 or `GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 15636 construct. 15637 15638 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 15639 Return the kind of try block represented by `GIMPLE_TRY' `G'. This 15640 is either `GIMPLE_TRY_CATCH' or `GIMPLE_TRY_FINALLY'. 15641 15642 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 15643 Return the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15644 15645 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 15646 Return the sequence of statements used as the body for `GIMPLE_TRY' 15647 `G'. 15648 15649 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 15650 Return the sequence of statements used as the cleanup body for 15651 `GIMPLE_TRY' `G'. 15652 15653 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 15654 bool catch_is_cleanup) 15655 Set the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 15656 15657 -- GIMPLE function: void gimple_try_set_eval (gimple g, gimple_seq 15658 eval) 15659 Set `EVAL' to be the sequence of statements to use as the body for 15660 `GIMPLE_TRY' `G'. 15661 15662 -- GIMPLE function: void gimple_try_set_cleanup (gimple g, gimple_seq 15663 cleanup) 15664 Set `CLEANUP' to be the sequence of statements to use as the 15665 cleanup body for `GIMPLE_TRY' `G'. 15666 15667 15668File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors 15669 1567012.7.28 `GIMPLE_WITH_CLEANUP_EXPR' 15671---------------------------------- 15672 15673 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 15674 Build a `GIMPLE_WITH_CLEANUP_EXPR' statement. `CLEANUP' is the 15675 clean-up expression. 15676 15677 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 15678 Return the cleanup sequence for cleanup statement `G'. 15679 15680 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 15681 cleanup) 15682 Set `CLEANUP' to be the cleanup sequence for `G'. 15683 15684 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 15685 Return the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15686 15687 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, 15688 bool eh_only_p) 15689 Set the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 15690 15691 15692File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 15693 1569412.8 GIMPLE sequences 15695===================== 15696 15697GIMPLE sequences are the tuple equivalent of `STATEMENT_LIST''s used in 15698`GENERIC'. They are used to chain statements together, and when used 15699in conjunction with sequence iterators, provide a framework for 15700iterating through statements. 15701 15702 GIMPLE sequences are of type struct `gimple_sequence', but are more 15703commonly passed by reference to functions dealing with sequences. The 15704type for a sequence pointer is `gimple_seq' which is the same as struct 15705`gimple_sequence' *. When declaring a local sequence, you can define a 15706local variable of type struct `gimple_sequence'. When declaring a 15707sequence allocated on the garbage collected heap, use the function 15708`gimple_seq_alloc' documented below. 15709 15710 There are convenience functions for iterating through sequences in the 15711section entitled Sequence Iterators. 15712 15713 Below is a list of functions to manipulate and query sequences. 15714 15715 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 15716 g) 15717 Link a gimple statement to the end of the sequence *`SEQ' if `G' is 15718 not `NULL'. If *`SEQ' is `NULL', allocate a sequence before 15719 linking. 15720 15721 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 15722 gimple_seq src) 15723 Append sequence `SRC' to the end of sequence *`DEST' if `SRC' is 15724 not `NULL'. If *`DEST' is `NULL', allocate a new sequence before 15725 appending. 15726 15727 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 15728 Perform a deep copy of sequence `SRC' and return the result. 15729 15730 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 15731 Reverse the order of the statements in the sequence `SEQ'. Return 15732 `SEQ'. 15733 15734 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 15735 Return the first statement in sequence `S'. 15736 15737 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 15738 Return the last statement in sequence `S'. 15739 15740 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 15741 last) 15742 Set the last statement in sequence `S' to the statement in `LAST'. 15743 15744 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 15745 first) 15746 Set the first statement in sequence `S' to the statement in 15747 `FIRST'. 15748 15749 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 15750 Initialize sequence `S' to an empty sequence. 15751 15752 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 15753 Allocate a new sequence in the garbage collected store and return 15754 it. 15755 15756 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 15757 src) 15758 Copy the sequence `SRC' into the sequence `DEST'. 15759 15760 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 15761 Return true if the sequence `S' is empty. 15762 15763 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 15764 Returns the sequence of statements in `BB'. 15765 15766 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 15767 Sets the sequence of statements in `BB' to `SEQ'. 15768 15769 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 15770 Determine whether `SEQ' contains exactly one statement. 15771 15772 15773File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 15774 1577512.9 Sequence iterators 15776======================= 15777 15778Sequence iterators are convenience constructs for iterating through 15779statements in a sequence. Given a sequence `SEQ', here is a typical 15780use of gimple sequence iterators: 15781 15782 gimple_stmt_iterator gsi; 15783 15784 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 15785 { 15786 gimple g = gsi_stmt (gsi); 15787 /* Do something with gimple statement `G'. */ 15788 } 15789 15790 Backward iterations are possible: 15791 15792 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 15793 15794 Forward and backward iterations on basic blocks are possible with 15795`gsi_start_bb' and `gsi_last_bb'. 15796 15797 In the documentation below we sometimes refer to enum 15798`gsi_iterator_update'. The valid options for this enumeration are: 15799 15800 * `GSI_NEW_STMT' Only valid when a single statement is added. Move 15801 the iterator to it. 15802 15803 * `GSI_SAME_STMT' Leave the iterator at the same statement. 15804 15805 * `GSI_CONTINUE_LINKING' Move iterator to whatever position is 15806 suitable for linking other statements in the same direction. 15807 15808 Below is a list of the functions used to manipulate and use statement 15809iterators. 15810 15811 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 15812 Return a new iterator pointing to the sequence `SEQ''s first 15813 statement. If `SEQ' is empty, the iterator's basic block is 15814 `NULL'. Use `gsi_start_bb' instead when the iterator needs to 15815 always have the correct basic block set. 15816 15817 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 15818 Return a new iterator pointing to the first statement in basic 15819 block `BB'. 15820 15821 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 15822 Return a new iterator initially pointing to the last statement of 15823 sequence `SEQ'. If `SEQ' is empty, the iterator's basic block is 15824 `NULL'. Use `gsi_last_bb' instead when the iterator needs to 15825 always have the correct basic block set. 15826 15827 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 15828 Return a new iterator pointing to the last statement in basic 15829 block `BB'. 15830 15831 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 15832 Return `TRUE' if at the end of `I'. 15833 15834 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 15835 Return `TRUE' if we're one statement before the end of `I'. 15836 15837 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 15838 Advance the iterator to the next gimple statement. 15839 15840 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 15841 Advance the iterator to the previous gimple statement. 15842 15843 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 15844 Return the current stmt. 15845 15846 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 15847 bb) 15848 Return a block statement iterator that points to the first 15849 non-label statement in block `BB'. 15850 15851 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 15852 Return a pointer to the current stmt. 15853 15854 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 15855 Return the basic block associated with this iterator. 15856 15857 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 15858 Return the sequence associated with this iterator. 15859 15860 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 15861 remove_eh_info) 15862 Remove the current stmt from the sequence. The iterator is 15863 updated to point to the next statement. When `REMOVE_EH_INFO' is 15864 true we remove the statement pointed to by iterator `I' from the 15865 `EH' tables. Otherwise we do not modify the `EH' tables. 15866 Generally, `REMOVE_EH_INFO' should be true when the statement is 15867 going to be removed from the `IL' and not reinserted elsewhere. 15868 15869 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 15870 gimple_seq seq, enum gsi_iterator_update mode) 15871 Links the sequence of statements `SEQ' before the statement pointed 15872 by iterator `I'. `MODE' indicates what to do with the iterator 15873 after insertion (see `enum gsi_iterator_update' above). 15874 15875 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 15876 gimple g, enum gsi_iterator_update mode) 15877 Links statement `G' before the statement pointed-to by iterator 15878 `I'. Updates iterator `I' according to `MODE'. 15879 15880 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 15881 gimple_seq seq, enum gsi_iterator_update mode) 15882 Links sequence `SEQ' after the statement pointed-to by iterator 15883 `I'. `MODE' is as in `gsi_insert_after'. 15884 15885 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 15886 gimple g, enum gsi_iterator_update mode) 15887 Links statement `G' after the statement pointed-to by iterator `I'. 15888 `MODE' is as in `gsi_insert_after'. 15889 15890 -- GIMPLE function: gimple_seq gsi_split_seq_after 15891 (gimple_stmt_iterator i) 15892 Move all statements in the sequence after `I' to a new sequence. 15893 Return this new sequence. 15894 15895 -- GIMPLE function: gimple_seq gsi_split_seq_before 15896 (gimple_stmt_iterator *i) 15897 Move all statements in the sequence before `I' to a new sequence. 15898 Return this new sequence. 15899 15900 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 15901 stmt, bool update_eh_info) 15902 Replace the statement pointed-to by `I' to `STMT'. If 15903 `UPDATE_EH_INFO' is true, the exception handling information of 15904 the original statement is moved to the new statement. 15905 15906 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 15907 gimple stmt, enum gsi_iterator_update mode) 15908 Insert statement `STMT' before the statement pointed-to by iterator 15909 `I', update `STMT''s basic block and scan it for new operands. 15910 `MODE' specifies how to update iterator `I' after insertion (see 15911 enum `gsi_iterator_update'). 15912 15913 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 15914 *i, gimple_seq seq, enum gsi_iterator_update mode) 15915 Like `gsi_insert_before', but for all the statements in `SEQ'. 15916 15917 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 15918 gimple stmt, enum gsi_iterator_update mode) 15919 Insert statement `STMT' after the statement pointed-to by iterator 15920 `I', update `STMT''s basic block and scan it for new operands. 15921 `MODE' specifies how to update iterator `I' after insertion (see 15922 enum `gsi_iterator_update'). 15923 15924 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator 15925 *i, gimple_seq seq, enum gsi_iterator_update mode) 15926 Like `gsi_insert_after', but for all the statements in `SEQ'. 15927 15928 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 15929 Finds iterator for `STMT'. 15930 15931 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 15932 gimple_stmt_iterator *to) 15933 Move the statement at `FROM' so it comes right after the statement 15934 at `TO'. 15935 15936 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 15937 gimple_stmt_iterator *to) 15938 Move the statement at `FROM' so it comes right before the statement 15939 at `TO'. 15940 15941 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 15942 *from, basic_block bb) 15943 Move the statement at `FROM' to the end of basic block `BB'. 15944 15945 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 15946 Add `STMT' to the pending list of edge `E'. No actual insertion is 15947 made until a call to `gsi_commit_edge_inserts'() is made. 15948 15949 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 15950 seq) 15951 Add the sequence of statements in `SEQ' to the pending list of edge 15952 `E'. No actual insertion is made until a call to 15953 `gsi_commit_edge_inserts'() is made. 15954 15955 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 15956 gimple stmt) 15957 Similar to `gsi_insert_on_edge'+`gsi_commit_edge_inserts'. If a 15958 new block has to be created, it is returned. 15959 15960 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 15961 basic_block *new_bb) 15962 Commit insertions pending at edge `E'. If a new block is created, 15963 set `NEW_BB' to this block, otherwise set it to `NULL'. 15964 15965 -- GIMPLE function: void gsi_commit_edge_inserts (void) 15966 This routine will commit all pending edge insertions, creating any 15967 new basic blocks which are necessary. 15968 15969 15970File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 15971 1597212.10 Adding a new GIMPLE statement code 15973======================================== 15974 15975The first step in adding a new GIMPLE statement code, is modifying the 15976file `gimple.def', which contains all the GIMPLE codes. Then you must 15977add a corresponding structure, and an entry in `union 15978gimple_statement_d', both of which are located in `gimple.h'. This in 15979turn, will require you to add a corresponding `GTY' tag in 15980`gsstruct.def', and code to handle this tag in `gss_for_code' which is 15981located in `gimple.c'. 15982 15983 In order for the garbage collector to know the size of the structure 15984you created in `gimple.h', you need to add a case to handle your new 15985GIMPLE statement in `gimple_size' which is located in `gimple.c'. 15986 15987 You will probably want to create a function to build the new gimple 15988statement in `gimple.c'. The function should be called 15989`gimple_build_NEW-TUPLE-NAME', and should return the new tuple of type 15990gimple. 15991 15992 If your new statement requires accessors for any members or operands 15993it may have, put simple inline accessors in `gimple.h' and any 15994non-trivial accessors in `gimple.c' with a corresponding prototype in 15995`gimple.h'. 15996 15997 15998File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 15999 1600012.11 Statement and operand traversals 16001====================================== 16002 16003There are two functions available for walking statements and sequences: 16004`walk_gimple_stmt' and `walk_gimple_seq', accordingly, and a third 16005function for walking the operands in a statement: `walk_gimple_op'. 16006 16007 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 16008 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 16009 walk_stmt_info *wi) 16010 This function is used to walk the current statement in `GSI', 16011 optionally using traversal state stored in `WI'. If `WI' is 16012 `NULL', no state is kept during the traversal. 16013 16014 The callback `CALLBACK_STMT' is called. If `CALLBACK_STMT' returns 16015 true, it means that the callback function has handled all the 16016 operands of the statement and it is not necessary to walk its 16017 operands. 16018 16019 If `CALLBACK_STMT' is `NULL' or it returns false, `CALLBACK_OP' is 16020 called on each operand of the statement via `walk_gimple_op'. If 16021 `walk_gimple_op' returns non-`NULL' for any operand, the remaining 16022 operands are not scanned. 16023 16024 The return value is that returned by the last call to 16025 `walk_gimple_op', or `NULL_TREE' if no `CALLBACK_OP' is specified. 16026 16027 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 16028 callback_op, struct walk_stmt_info *wi) 16029 Use this function to walk the operands of statement `STMT'. Every 16030 operand is walked via `walk_tree' with optional state information 16031 in `WI'. 16032 16033 `CALLBACK_OP' is called on each operand of `STMT' via `walk_tree'. 16034 Additional parameters to `walk_tree' must be stored in `WI'. For 16035 each operand `OP', `walk_tree' is called as: 16036 16037 walk_tree (&`OP', `CALLBACK_OP', `WI', `PSET') 16038 16039 If `CALLBACK_OP' returns non-`NULL' for an operand, the remaining 16040 operands are not scanned. The return value is that returned by 16041 the last call to `walk_tree', or `NULL_TREE' if no `CALLBACK_OP' is 16042 specified. 16043 16044 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 16045 callback_stmt, walk_tree_fn callback_op, struct 16046 walk_stmt_info *wi) 16047 This function walks all the statements in the sequence `SEQ' 16048 calling `walk_gimple_stmt' on each one. `WI' is as in 16049 `walk_gimple_stmt'. If `walk_gimple_stmt' returns non-`NULL', the 16050 walk is stopped and the value returned. Otherwise, all the 16051 statements are walked and `NULL_TREE' returned. 16052 16053 16054File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 16055 1605613 Analysis and Optimization of GIMPLE tuples 16057********************************************* 16058 16059GCC uses three main intermediate languages to represent the program 16060during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 16061language-independent representation generated by each front end. It is 16062used to serve as an interface between the parser and optimizer. 16063GENERIC is a common representation that is able to represent programs 16064written in all the languages supported by GCC. 16065 16066 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 16067target and language independent optimizations (e.g., inlining, constant 16068propagation, tail call elimination, redundancy elimination, etc). Much 16069like GENERIC, GIMPLE is a language independent, tree based 16070representation. However, it differs from GENERIC in that the GIMPLE 16071grammar is more restrictive: expressions contain no more than 3 16072operands (except function calls), it has no control flow structures and 16073expressions with side-effects are only allowed on the right hand side 16074of assignments. See the chapter describing GENERIC and GIMPLE for more 16075details. 16076 16077 This chapter describes the data structures and functions used in the 16078GIMPLE optimizers (also known as "tree optimizers" or "middle end"). 16079In particular, it focuses on all the macros, data structures, functions 16080and programming constructs needed to implement optimization passes for 16081GIMPLE. 16082 16083* Menu: 16084 16085* Annotations:: Attributes for variables. 16086* SSA Operands:: SSA names referenced by GIMPLE statements. 16087* SSA:: Static Single Assignment representation. 16088* Alias analysis:: Representing aliased loads and stores. 16089* Memory model:: Memory model used by the middle-end. 16090 16091 16092File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 16093 1609413.1 Annotations 16095================ 16096 16097The optimizers need to associate attributes with variables during the 16098optimization process. For instance, we need to know whether a variable 16099has aliases. All these attributes are stored in data structures called 16100annotations which are then linked to the field `ann' in `struct 16101tree_common'. 16102 16103 Presently, we define annotations for variables (`var_ann_t'). 16104Annotations are defined and documented in `tree-flow.h'. 16105 16106 16107File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 16108 1610913.2 SSA Operands 16110================= 16111 16112Almost every GIMPLE statement will contain a reference to a variable or 16113memory location. Since statements come in different shapes and sizes, 16114their operands are going to be located at various spots inside the 16115statement's tree. To facilitate access to the statement's operands, 16116they are organized into lists associated inside each statement's 16117annotation. Each element in an operand list is a pointer to a 16118`VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very 16119convenient way of examining and replacing operands. 16120 16121 Data flow analysis and optimization is done on all tree nodes 16122representing variables. Any node for which `SSA_VAR_P' returns nonzero 16123is considered when scanning statement operands. However, not all 16124`SSA_VAR_P' variables are processed in the same way. For the purposes 16125of optimization, we need to distinguish between references to local 16126scalar variables and references to globals, statics, structures, 16127arrays, aliased variables, etc. The reason is simple, the compiler can 16128gather complete data flow information for a local scalar. On the other 16129hand, a global variable may be modified by a function call, it may not 16130be possible to keep track of all the elements of an array or the fields 16131of a structure, etc. 16132 16133 The operand scanner gathers two kinds of operands: "real" and 16134"virtual". An operand for which `is_gimple_reg' returns true is 16135considered real, otherwise it is a virtual operand. We also 16136distinguish between uses and definitions. An operand is used if its 16137value is loaded by the statement (e.g., the operand at the RHS of an 16138assignment). If the statement assigns a new value to the operand, the 16139operand is considered a definition (e.g., the operand at the LHS of an 16140assignment). 16141 16142 Virtual and real operands also have very different data flow 16143properties. Real operands are unambiguous references to the full 16144object that they represent. For instance, given 16145 16146 { 16147 int a, b; 16148 a = b 16149 } 16150 16151 Since `a' and `b' are non-aliased locals, the statement `a = b' will 16152have one real definition and one real use because variable `a' is 16153completely modified with the contents of variable `b'. Real definition 16154are also known as "killing definitions". Similarly, the use of `b' 16155reads all its bits. 16156 16157 In contrast, virtual operands are used with variables that can have a 16158partial or ambiguous reference. This includes structures, arrays, 16159globals, and aliased variables. In these cases, we have two types of 16160definitions. For globals, structures, and arrays, we can determine from 16161a statement whether a variable of these types has a killing definition. 16162If the variable does, then the statement is marked as having a "must 16163definition" of that variable. However, if a statement is only defining 16164a part of the variable (i.e. a field in a structure), or if we know 16165that a statement might define the variable but we cannot say for sure, 16166then we mark that statement as having a "may definition". For 16167instance, given 16168 16169 { 16170 int a, b, *p; 16171 16172 if (...) 16173 p = &a; 16174 else 16175 p = &b; 16176 *p = 5; 16177 return *p; 16178 } 16179 16180 The assignment `*p = 5' may be a definition of `a' or `b'. If we 16181cannot determine statically where `p' is pointing to at the time of the 16182store operation, we create virtual definitions to mark that statement 16183as a potential definition site for `a' and `b'. Memory loads are 16184similarly marked with virtual use operands. Virtual operands are shown 16185in tree dumps right before the statement that contains them. To 16186request a tree dump with virtual operands, use the `-vops' option to 16187`-fdump-tree': 16188 16189 { 16190 int a, b, *p; 16191 16192 if (...) 16193 p = &a; 16194 else 16195 p = &b; 16196 # a = VDEF <a> 16197 # b = VDEF <b> 16198 *p = 5; 16199 16200 # VUSE <a> 16201 # VUSE <b> 16202 return *p; 16203 } 16204 16205 Notice that `VDEF' operands have two copies of the referenced 16206variable. This indicates that this is not a killing definition of that 16207variable. In this case we refer to it as a "may definition" or 16208"aliased store". The presence of the second copy of the variable in 16209the `VDEF' operand will become important when the function is converted 16210into SSA form. This will be used to link all the non-killing 16211definitions to prevent optimizations from making incorrect assumptions 16212about them. 16213 16214 Operands are updated as soon as the statement is finished via a call 16215to `update_stmt'. If statement elements are changed via `SET_USE' or 16216`SET_DEF', then no further action is required (i.e., those macros take 16217care of updating the statement). If changes are made by manipulating 16218the statement's tree directly, then a call must be made to 16219`update_stmt' when complete. Calling one of the `bsi_insert' routines 16220or `bsi_replace' performs an implicit call to `update_stmt'. 16221 1622213.2.1 Operand Iterators And Access Routines 16223-------------------------------------------- 16224 16225Operands are collected by `tree-ssa-operands.c'. They are stored 16226inside each statement's annotation and can be accessed through either 16227the operand iterators or an access routine. 16228 16229 The following access routines are available for examining operands: 16230 16231 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 16232 NULL unless there is exactly one operand matching the specified 16233 flags. If there is exactly one operand, the operand is returned 16234 as either a `tree', `def_operand_p', or `use_operand_p'. 16235 16236 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 16237 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 16238 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 16239 16240 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no 16241 operands matching the specified flags. 16242 16243 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 16244 return; 16245 16246 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands 16247 matching 'flags'. This actually executes a loop to perform the 16248 count, so only use this if it is really needed. 16249 16250 int count = NUM_SSA_OPERANDS (stmt, flags) 16251 16252 If you wish to iterate over some or all operands, use the 16253`FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 16254all the operands for a statement: 16255 16256 void 16257 print_ops (tree stmt) 16258 { 16259 ssa_op_iter; 16260 tree var; 16261 16262 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 16263 print_generic_expr (stderr, var, TDF_SLIM); 16264 } 16265 16266 How to choose the appropriate iterator: 16267 16268 1. Determine whether you are need to see the operand pointers, or 16269 just the trees, and choose the appropriate macro: 16270 16271 Need Macro: 16272 ---- ------- 16273 use_operand_p FOR_EACH_SSA_USE_OPERAND 16274 def_operand_p FOR_EACH_SSA_DEF_OPERAND 16275 tree FOR_EACH_SSA_TREE_OPERAND 16276 16277 2. You need to declare a variable of the type you are interested in, 16278 and an ssa_op_iter structure which serves as the loop controlling 16279 variable. 16280 16281 3. Determine which operands you wish to use, and specify the flags of 16282 those you are interested in. They are documented in 16283 `tree-ssa-operands.h': 16284 16285 #define SSA_OP_USE 0x01 /* Real USE operands. */ 16286 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 16287 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 16288 #define SSA_OP_VMAYUSE 0x08 /* USE portion of VDEFS. */ 16289 #define SSA_OP_VDEF 0x10 /* DEF portion of VDEFS. */ 16290 16291 /* These are commonly grouped operand flags. */ 16292 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE) 16293 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 16294 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 16295 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 16296 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 16297 16298 So if you want to look at the use pointers for all the `USE' and 16299`VUSE' operands, you would do something like: 16300 16301 use_operand_p use_p; 16302 ssa_op_iter iter; 16303 16304 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 16305 { 16306 process_use_ptr (use_p); 16307 } 16308 16309 The `TREE' macro is basically the same as the `USE' and `DEF' macros, 16310only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and 16311`DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use 16312and defs flags can be mixed. 16313 16314 tree var; 16315 ssa_op_iter iter; 16316 16317 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 16318 { 16319 print_generic_expr (stderr, var, TDF_SLIM); 16320 } 16321 16322 `VDEF's are broken into two flags, one for the `DEF' portion 16323(`SSA_OP_VDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If all 16324you want to look at are the `VDEF's together, there is a fourth 16325iterator macro for this, which returns both a def_operand_p and a 16326use_operand_p for each `VDEF' in the statement. Note that you don't 16327need any flags for this one. 16328 16329 use_operand_p use_p; 16330 def_operand_p def_p; 16331 ssa_op_iter iter; 16332 16333 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter) 16334 { 16335 my_code; 16336 } 16337 16338 There are many examples in the code as well, as well as the 16339documentation in `tree-ssa-operands.h'. 16340 16341 There are also a couple of variants on the stmt iterators regarding PHI 16342nodes. 16343 16344 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND', 16345except it works over `PHI' arguments instead of statement operands. 16346 16347 /* Look at every virtual PHI use. */ 16348 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 16349 { 16350 my_code; 16351 } 16352 16353 /* Look at every real PHI use. */ 16354 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 16355 my_code; 16356 16357 /* Look at every PHI use. */ 16358 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 16359 my_code; 16360 16361 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 16362`FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 16363statement or a `PHI' node. These should be used when it is appropriate 16364but they are not quite as efficient as the individual `FOR_EACH_PHI' 16365and `FOR_EACH_SSA' routines. 16366 16367 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 16368 { 16369 my_code; 16370 } 16371 16372 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 16373 { 16374 my_code; 16375 } 16376 1637713.2.2 Immediate Uses 16378--------------------- 16379 16380Immediate use information is now always available. Using the immediate 16381use iterators, you may examine every use of any `SSA_NAME'. For 16382instance, to change each use of `ssa_var' to `ssa_var2' and call 16383fold_stmt on each stmt after that is done: 16384 16385 use_operand_p imm_use_p; 16386 imm_use_iterator iterator; 16387 tree ssa_var, stmt; 16388 16389 16390 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 16391 { 16392 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 16393 SET_USE (imm_use_p, ssa_var_2); 16394 fold_stmt (stmt); 16395 } 16396 16397 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is 16398used when the immediate uses are not changed, i.e., you are looking at 16399the uses, but not setting them. 16400 16401 If they do get changed, then care must be taken that things are not 16402changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and 16403`FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 16404sanity of the use list by moving all the uses for a statement into a 16405controlled position, and then iterating over those uses. Then the 16406optimization can manipulate the stmt when all the uses have been 16407processed. This is a little slower than the FAST version since it adds 16408a placeholder element and must sort through the list a bit for each 16409statement. This placeholder element must be also be removed if the 16410loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is 16411provided to do this : 16412 16413 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 16414 { 16415 if (stmt == last_stmt) 16416 BREAK_FROM_SAFE_IMM_USE (iter); 16417 16418 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 16419 SET_USE (imm_use_p, ssa_var_2); 16420 fold_stmt (stmt); 16421 } 16422 16423 There are checks in `verify_ssa' which verify that the immediate use 16424list is up to date, as well as checking that an optimization didn't 16425break from the loop without using this macro. It is safe to simply 16426'break'; from a `FOR_EACH_IMM_USE_FAST' traverse. 16427 16428 Some useful functions and macros: 16429 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of 16430 `ssa_var'. 16431 16432 2. `has_single_use (ssa_var)' : Returns true if there is only a 16433 single use of `ssa_var'. 16434 16435 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 16436 Returns true if there is only a single use of `ssa_var', and also 16437 returns the use pointer and statement it occurs in, in the second 16438 and third parameters. 16439 16440 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of 16441 `ssa_var'. It is better not to use this if possible since it simply 16442 utilizes a loop to count the uses. 16443 16444 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI' 16445 node, return the index number for the use. An assert is triggered 16446 if the use isn't located in a `PHI' node. 16447 16448 6. `USE_STMT (use_p)' : Return the statement a use occurs in. 16449 16450 Note that uses are not put into an immediate use list until their 16451statement is actually inserted into the instruction stream via a 16452`bsi_*' routine. 16453 16454 It is also still possible to utilize lazy updating of statements, but 16455this should be used only when absolutely required. Both alias analysis 16456and the dominator optimizations currently do this. 16457 16458 When lazy updating is being used, the immediate use information is out 16459of date and cannot be used reliably. Lazy updating is achieved by 16460simply marking statements modified via calls to `mark_stmt_modified' 16461instead of `update_stmt'. When lazy updating is no longer required, 16462all the modified statements must have `update_stmt' called in order to 16463bring them up to date. This must be done before the optimization is 16464finished, or `verify_ssa' will trigger an abort. 16465 16466 This is done with a simple loop over the instruction stream: 16467 block_stmt_iterator bsi; 16468 basic_block bb; 16469 FOR_EACH_BB (bb) 16470 { 16471 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 16472 update_stmt_if_modified (bsi_stmt (bsi)); 16473 } 16474 16475 16476File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 16477 1647813.3 Static Single Assignment 16479============================= 16480 16481Most of the tree optimizers rely on the data flow information provided 16482by the Static Single Assignment (SSA) form. We implement the SSA form 16483as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 16484Zadeck. Efficiently Computing Static Single Assignment Form and the 16485Control Dependence Graph. ACM Transactions on Programming Languages 16486and Systems, 13(4):451-490, October 1991'. 16487 16488 The SSA form is based on the premise that program variables are 16489assigned in exactly one location in the program. Multiple assignments 16490to the same variable create new versions of that variable. Naturally, 16491actual programs are seldom in SSA form initially because variables tend 16492to be assigned multiple times. The compiler modifies the program 16493representation so that every time a variable is assigned in the code, a 16494new version of the variable is created. Different versions of the same 16495variable are distinguished by subscripting the variable name with its 16496version number. Variables used in the right-hand side of expressions 16497are renamed so that their version number matches that of the most 16498recent assignment. 16499 16500 We represent variable versions using `SSA_NAME' nodes. The renaming 16501process in `tree-ssa.c' wraps every real and virtual operand with an 16502`SSA_NAME' node which contains the version number and the statement 16503that created the `SSA_NAME'. Only definitions and virtual definitions 16504may create new `SSA_NAME' nodes. 16505 16506 Sometimes, flow of control makes it impossible to determine the most 16507recent version of a variable. In these cases, the compiler inserts an 16508artificial definition for that variable called "PHI function" or "PHI 16509node". This new definition merges all the incoming versions of the 16510variable to create a new name for it. For instance, 16511 16512 if (...) 16513 a_1 = 5; 16514 else if (...) 16515 a_2 = 2; 16516 else 16517 a_3 = 13; 16518 16519 # a_4 = PHI <a_1, a_2, a_3> 16520 return a_4; 16521 16522 Since it is not possible to determine which of the three branches will 16523be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to 16524use at the return statement. So, the SSA renamer creates a new version 16525`a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'. 16526Hence, PHI nodes mean "one of these operands. I don't know which". 16527 16528 The following macros can be used to examine PHI nodes 16529 16530 -- Macro: PHI_RESULT (PHI) 16531 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 16532 16533 -- Macro: PHI_NUM_ARGS (PHI) 16534 Returns the number of arguments in PHI. This number is exactly 16535 the number of incoming edges to the basic block holding PHI. 16536 16537 -- Macro: PHI_ARG_ELT (PHI, I) 16538 Returns a tuple representing the Ith argument of PHI. Each 16539 element of this tuple contains an `SSA_NAME' VAR and the incoming 16540 edge through which VAR flows. 16541 16542 -- Macro: PHI_ARG_EDGE (PHI, I) 16543 Returns the incoming edge for the Ith argument of PHI. 16544 16545 -- Macro: PHI_ARG_DEF (PHI, I) 16546 Returns the `SSA_NAME' for the Ith argument of PHI. 16547 1654813.3.1 Preserving the SSA form 16549------------------------------ 16550 16551Some optimization passes make changes to the function that invalidate 16552the SSA property. This can happen when a pass has added new symbols or 16553changed the program so that variables that were previously aliased 16554aren't anymore. Whenever something like this happens, the affected 16555symbols must be renamed into SSA form again. Transformations that emit 16556new code or replicate existing statements will also need to update the 16557SSA form. 16558 16559 Since GCC implements two different SSA forms for register and virtual 16560variables, keeping the SSA form up to date depends on whether you are 16561updating register or virtual names. In both cases, the general idea 16562behind incremental SSA updates is similar: when new SSA names are 16563created, they typically are meant to replace other existing names in 16564the program. 16565 16566 For instance, given the following code: 16567 16568 1 L0: 16569 2 x_1 = PHI (0, x_5) 16570 3 if (x_1 < 10) 16571 4 if (x_1 > 7) 16572 5 y_2 = 0 16573 6 else 16574 7 y_3 = x_1 + x_7 16575 8 endif 16576 9 x_5 = x_1 + 1 16577 10 goto L0; 16578 11 endif 16579 16580 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8'). 16581 16582 1 L0: 16583 2 x_1 = PHI (0, x_5) 16584 3 if (x_1 < 10) 16585 4 x_10 = ... 16586 5 if (x_1 > 7) 16587 6 y_2 = 0 16588 7 else 16589 8 x_11 = ... 16590 9 y_3 = x_1 + x_7 16591 10 endif 16592 11 x_5 = x_1 + 1 16593 12 goto L0; 16594 13 endif 16595 16596 We want to replace all the uses of `x_1' with the new definitions of 16597`x_10' and `x_11'. Note that the only uses that should be replaced are 16598those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9' 16599should _not_ be replaced (this is why we cannot just mark symbol `x' for 16600renaming). 16601 16602 Additionally, we may need to insert a PHI node at line `11' because 16603that is a merge point for `x_10' and `x_11'. So the use of `x_1' at 16604line `11' will be replaced with the new PHI node. The insertion of PHI 16605nodes is optional. They are not strictly necessary to preserve the SSA 16606form, and depending on what the caller inserted, they may not even be 16607useful for the optimizers. 16608 16609 Updating the SSA form is a two step process. First, the pass has to 16610identify which names need to be updated and/or which symbols need to be 16611renamed into SSA form for the first time. When new names are 16612introduced to replace existing names in the program, the mapping 16613between the old and the new names are registered by calling 16614`register_new_name_mapping' (note that if your pass creates new code by 16615duplicating basic blocks, the call to `tree_duplicate_bb' will set up 16616the necessary mappings automatically). 16617 16618 After the replacement mappings have been registered and new symbols 16619marked for renaming, a call to `update_ssa' makes the registered 16620changes. This can be done with an explicit call or by creating `TODO' 16621flags in the `tree_opt_pass' structure for your pass. There are 16622several `TODO' flags that control the behavior of `update_ssa': 16623 16624 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes for 16625 newly exposed symbols and virtual names marked for updating. When 16626 updating real names, only insert PHI nodes for a real name `O_j' 16627 in blocks reached by all the new and old definitions for `O_j'. 16628 If the iterated dominance frontier for `O_j' is not pruned, we may 16629 end up inserting PHI nodes in blocks that have one or more edges 16630 with no incoming definition for `O_j'. This would lead to 16631 uninitialized warnings for `O_j''s symbol. 16632 16633 * `TODO_update_ssa_no_phi'. Update the SSA form without inserting 16634 any new PHI nodes at all. This is used by passes that have either 16635 inserted all the PHI nodes themselves or passes that need only to 16636 patch use-def and def-def chains for virtuals (e.g., DCE). 16637 16638 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 16639 needed. No pruning of the IDF is done. This is used by passes 16640 that need the PHI nodes for `O_j' even if it means that some 16641 arguments will come from the default definition of `O_j''s symbol 16642 (e.g., `pass_linear_transform'). 16643 16644 WARNING: If you need to use this flag, chances are that your pass 16645 may be doing something wrong. Inserting PHI nodes for an old name 16646 where not all edges carry a new replacement may lead to silent 16647 codegen errors or spurious uninitialized warnings. 16648 16649 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA form 16650 on their own may want to delegate the updating of virtual names to 16651 the generic updater. Since FUD chains are easier to maintain, 16652 this simplifies the work they need to do. NOTE: If this flag is 16653 used, any OLD->NEW mappings for real names are explicitly 16654 destroyed and only the symbols marked for renaming are processed. 16655 1665613.3.2 Preserving the virtual SSA form 16657-------------------------------------- 16658 16659The virtual SSA form is harder to preserve than the non-virtual SSA form 16660mainly because the set of virtual operands for a statement may change at 16661what some would consider unexpected times. In general, statement 16662modifications should be bracketed between calls to `push_stmt_changes' 16663and `pop_stmt_changes'. For example, 16664 16665 munge_stmt (tree stmt) 16666 { 16667 push_stmt_changes (&stmt); 16668 ... rewrite STMT ... 16669 pop_stmt_changes (&stmt); 16670 } 16671 16672 The call to `push_stmt_changes' saves the current state of the 16673statement operands and the call to `pop_stmt_changes' compares the 16674saved state with the current one and does the appropriate symbol 16675marking for the SSA renamer. 16676 16677 It is possible to modify several statements at a time, provided that 16678`push_stmt_changes' and `pop_stmt_changes' are called in LIFO order, as 16679when processing a stack of statements. 16680 16681 Additionally, if the pass discovers that it did not need to make 16682changes to the statement after calling `push_stmt_changes', it can 16683simply discard the topmost change buffer by calling 16684`discard_stmt_changes'. This will avoid the expensive operand re-scan 16685operation and the buffer comparison that determines if symbols need to 16686be marked for renaming. 16687 1668813.3.3 Examining `SSA_NAME' nodes 16689--------------------------------- 16690 16691The following macros can be used to examine `SSA_NAME' nodes 16692 16693 -- Macro: SSA_NAME_DEF_STMT (VAR) 16694 Returns the statement S that creates the `SSA_NAME' VAR. If S is 16695 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it 16696 means that the first reference to this variable is a USE or a VUSE. 16697 16698 -- Macro: SSA_NAME_VERSION (VAR) 16699 Returns the version number of the `SSA_NAME' object VAR. 16700 1670113.3.4 Walking use-def chains 16702----------------------------- 16703 16704 -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA) 16705 Walks use-def chains starting at the `SSA_NAME' node VAR. Calls 16706 function FN at each reaching definition found. Function FN takes 16707 three arguments: VAR, its defining statement (DEF_STMT) and a 16708 generic pointer to whatever state information that FN may want to 16709 maintain (DATA). Function FN is able to stop the walk by 16710 returning `true', otherwise in order to continue the walk, FN 16711 should return `false'. 16712 16713 Note, that if DEF_STMT is a `PHI' node, the semantics are slightly 16714 different. For each argument ARG of the PHI node, this function 16715 will: 16716 16717 1. Walk the use-def chains for ARG. 16718 16719 2. Call `FN (ARG, PHI, DATA)'. 16720 16721 Note how the first argument to FN is no longer the original 16722 variable VAR, but the PHI argument currently being examined. If 16723 FN wants to get at VAR, it should call `PHI_RESULT' (PHI). 16724 1672513.3.5 Walking the dominator tree 16726--------------------------------- 16727 16728 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 16729 This function walks the dominator tree for the current CFG calling 16730 a set of callback functions defined in STRUCT DOM_WALK_DATA in 16731 `domwalk.h'. The call back functions you need to define give you 16732 hooks to execute custom code at various points during traversal: 16733 16734 1. Once to initialize any local data needed while processing BB 16735 and its children. This local data is pushed into an internal 16736 stack which is automatically pushed and popped as the walker 16737 traverses the dominator tree. 16738 16739 2. Once before traversing all the statements in the BB. 16740 16741 3. Once for every statement inside BB. 16742 16743 4. Once after traversing all the statements and before recursing 16744 into BB's dominator children. 16745 16746 5. It then recurses into all the dominator children of BB. 16747 16748 6. After recursing into all the dominator children of BB it can, 16749 optionally, traverse every statement in BB again (i.e., 16750 repeating steps 2 and 3). 16751 16752 7. Once after walking the statements in BB and BB's dominator 16753 children. At this stage, the block local data stack is 16754 popped. 16755 16756 16757File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 16758 1675913.4 Alias analysis 16760=================== 16761 16762Alias analysis in GIMPLE SSA form consists of two pieces. First the 16763virtual SSA web ties conflicting memory accesses and provides a SSA 16764use-def chain and SSA immediate-use chains for walking possibly 16765dependent memory accesses. Second an alias-oracle can be queried to 16766disambiguate explicit and implicit memory references. 16767 16768 1. Memory SSA form. 16769 16770 All statements that may use memory have exactly one accompanied 16771 use of a virtual SSA name that represents the state of memory at 16772 the given point in the IL. 16773 16774 All statements that may define memory have exactly one accompanied 16775 definition of a virtual SSA name using the previous state of memory 16776 and defining the new state of memory after the given point in the 16777 IL. 16778 16779 int i; 16780 int foo (void) 16781 { 16782 # .MEM_3 = VDEF <.MEM_2(D)> 16783 i = 1; 16784 # VUSE <.MEM_3> 16785 return i; 16786 } 16787 16788 The virtual SSA names in this case are `.MEM_2(D)' and `.MEM_3'. 16789 The store to the global variable `i' defines `.MEM_3' invalidating 16790 `.MEM_2(D)'. The load from `i' uses that new state `.MEM_3'. 16791 16792 The virtual SSA web serves as constraints to SSA optimizers 16793 preventing illegitimate code-motion and optimization. It also 16794 provides a way to walk related memory statements. 16795 16796 2. Points-to and escape analysis. 16797 16798 Points-to analysis builds a set of constraints from the GIMPLE SSA 16799 IL representing all pointer operations and facts we do or do not 16800 know about pointers. Solving this set of constraints yields a 16801 conservatively correct solution for each pointer variable in the 16802 program (though we are only interested in SSA name pointers) as to 16803 what it may possibly point to. 16804 16805 This points-to solution for a given SSA name pointer is stored in 16806 the `pt_solution' sub-structure of the `SSA_NAME_PTR_INFO' record. 16807 The following accessor functions are available: 16808 16809 * `pt_solution_includes' 16810 16811 * `pt_solutions_intersect' 16812 16813 Points-to analysis also computes the solution for two special set 16814 of pointers, `ESCAPED' and `CALLUSED'. Those represent all memory 16815 that has escaped the scope of analysis or that is used by pure or 16816 nested const calls. 16817 16818 3. Type-based alias analysis 16819 16820 Type-based alias analysis is frontend dependent though generic 16821 support is provided by the middle-end in `alias.c'. TBAA code is 16822 used by both tree optimizers and RTL optimizers. 16823 16824 Every language that wishes to perform language-specific alias 16825 analysis should define a function that computes, given a `tree' 16826 node, an alias set for the node. Nodes in different alias sets 16827 are not allowed to alias. For an example, see the C front-end 16828 function `c_get_alias_set'. 16829 16830 4. Tree alias-oracle 16831 16832 The tree alias-oracle provides means to disambiguate two memory 16833 references and memory references against statements. The following 16834 queries are available: 16835 16836 * `refs_may_alias_p' 16837 16838 * `ref_maybe_used_by_stmt_p' 16839 16840 * `stmt_may_clobber_ref_p' 16841 16842 In addition to those two kind of statement walkers are available 16843 walking statements related to a reference ref. 16844 `walk_non_aliased_vuses' walks over dominating memory defining 16845 statements and calls back if the statement does not clobber ref 16846 providing the non-aliased VUSE. The walk stops at the first 16847 clobbering statement or if asked to. `walk_aliased_vdefs' walks 16848 over dominating memory defining statements and calls back on each 16849 statement clobbering ref providing its aliasing VDEF. The walk 16850 stops if asked to. 16851 16852 16853 16854File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 16855 1685613.5 Memory model 16857================= 16858 16859The memory model used by the middle-end models that of the C/C++ 16860languages. The middle-end has the notion of an effective type of a 16861memory region which is used for type-based alias analysis. 16862 16863 The following is a refinement of ISO C99 6.5/6, clarifying the block 16864copy case to follow common sense and extending the concept of a dynamic 16865effective type to objects with a declared type as required for C++. 16866 16867 The effective type of an object for an access to its stored value is 16868 the declared type of the object or the effective type determined by 16869 a previous store to it. If a value is stored into an object through 16870 an lvalue having a type that is not a character type, then the 16871 type of the lvalue becomes the effective type of the object for that 16872 access and for subsequent accesses that do not modify the stored value. 16873 If a value is copied into an object using `memcpy' or `memmove', 16874 or is copied as an array of character type, then the effective type 16875 of the modified object for that access and for subsequent accesses that 16876 do not modify the value is undetermined. For all other accesses to an 16877 object, the effective type of the object is simply the type of the 16878 lvalue used for the access. 16879 16880 16881File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 16882 1688314 Analysis and Representation of Loops 16884*************************************** 16885 16886GCC provides extensive infrastructure for work with natural loops, i.e., 16887strongly connected components of CFG with only one entry block. This 16888chapter describes representation of loops in GCC, both on GIMPLE and in 16889RTL, as well as the interfaces to loop-related analyses (induction 16890variable analysis and number of iterations analysis). 16891 16892* Menu: 16893 16894* Loop representation:: Representation and analysis of loops. 16895* Loop querying:: Getting information about loops. 16896* Loop manipulation:: Loop manipulation functions. 16897* LCSSA:: Loop-closed SSA form. 16898* Scalar evolutions:: Induction variables on GIMPLE. 16899* loop-iv:: Induction variables on RTL. 16900* Number of iterations:: Number of iterations analysis. 16901* Dependency analysis:: Data dependency analysis. 16902* Lambda:: Linear loop transformations framework. 16903* Omega:: A solver for linear programming problems. 16904 16905 16906File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 16907 1690814.1 Loop representation 16909======================== 16910 16911This chapter describes the representation of loops in GCC, and functions 16912that can be used to build, modify and analyze this representation. Most 16913of the interfaces and data structures are declared in `cfgloop.h'. At 16914the moment, loop structures are analyzed and this information is 16915updated only by the optimization passes that deal with loops, but some 16916efforts are being made to make it available throughout most of the 16917optimization passes. 16918 16919 In general, a natural loop has one entry block (header) and possibly 16920several back edges (latches) leading to the header from the inside of 16921the loop. Loops with several latches may appear if several loops share 16922a single header, or if there is a branching in the middle of the loop. 16923The representation of loops in GCC however allows only loops with a 16924single latch. During loop analysis, headers of such loops are split and 16925forwarder blocks are created in order to disambiguate their structures. 16926Heuristic based on profile information and structure of the induction 16927variables in the loops is used to determine whether the latches 16928correspond to sub-loops or to control flow in a single loop. This means 16929that the analysis sometimes changes the CFG, and if you run it in the 16930middle of an optimization pass, you must be able to deal with the new 16931blocks. You may avoid CFG changes by passing 16932`LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 16933however that most other loop manipulation functions will not work 16934correctly for loops with multiple latch edges (the functions that only 16935query membership of blocks to loops and subloop relationships, or 16936enumerate and test loop exits, can be expected to work). 16937 16938 Body of the loop is the set of blocks that are dominated by its header, 16939and reachable from its latch against the direction of edges in CFG. The 16940loops are organized in a containment hierarchy (tree) such that all the 16941loops immediately contained inside loop L are the children of L in the 16942tree. This tree is represented by the `struct loops' structure. The 16943root of this tree is a fake loop that contains all blocks in the 16944function. Each of the loops is represented in a `struct loop' 16945structure. Each loop is assigned an index (`num' field of the `struct 16946loop' structure), and the pointer to the loop is stored in the 16947corresponding field of the `larray' vector in the loops structure. The 16948indices do not have to be continuous, there may be empty (`NULL') 16949entries in the `larray' created by deleting loops. Also, there is no 16950guarantee on the relative order of a loop and its subloops in the 16951numbering. The index of a loop never changes. 16952 16953 The entries of the `larray' field should not be accessed directly. 16954The function `get_loop' returns the loop description for a loop with 16955the given index. `number_of_loops' function returns number of loops in 16956the function. To traverse all loops, use `FOR_EACH_LOOP' macro. The 16957`flags' argument of the macro is used to determine the direction of 16958traversal and the set of loops visited. Each loop is guaranteed to be 16959visited exactly once, regardless of the changes to the loop tree, and 16960the loops may be removed during the traversal. The newly created loops 16961are never traversed, if they need to be visited, this must be done 16962separately after their creation. The `FOR_EACH_LOOP' macro allocates 16963temporary variables. If the `FOR_EACH_LOOP' loop were ended using 16964break or goto, they would not be released; `FOR_EACH_LOOP_BREAK' macro 16965must be used instead. 16966 16967 Each basic block contains the reference to the innermost loop it 16968belongs to (`loop_father'). For this reason, it is only possible to 16969have one `struct loops' structure initialized at the same time for each 16970CFG. The global variable `current_loops' contains the `struct loops' 16971structure. Many of the loop manipulation functions assume that 16972dominance information is up-to-date. 16973 16974 The loops are analyzed through `loop_optimizer_init' function. The 16975argument of this function is a set of flags represented in an integer 16976bitmask. These flags specify what other properties of the loop 16977structures should be calculated/enforced and preserved later: 16978 16979 * `LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 16980 to CFG will be performed in the loop analysis, in particular, 16981 loops with multiple latch edges will not be disambiguated. If a 16982 loop has multiple latches, its latch block is set to NULL. Most of 16983 the loop manipulation functions will not work for loops in this 16984 shape. No other flags that require CFG changes can be passed to 16985 loop_optimizer_init. 16986 16987 * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a 16988 way that each loop has only one entry edge, and additionally, the 16989 source block of this entry edge has only one successor. This 16990 creates a natural place where the code can be moved out of the 16991 loop, and ensures that the entry edge of the loop leads from its 16992 immediate super-loop. 16993 16994 * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 16995 the latch block of each loop to have only one successor. This 16996 ensures that the latch of the loop does not belong to any of its 16997 sub-loops, and makes manipulation with the loops significantly 16998 easier. Most of the loop manipulation functions assume that the 16999 loops are in this shape. Note that with this flag, the "normal" 17000 loop without any control flow inside and with one exit consists of 17001 two basic blocks. 17002 17003 * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 17004 the strongly connected components that are not natural loops (have 17005 more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP' 17006 and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 17007 and edges that belong to natural loops that are in such an 17008 irreducible region (but it is set for the entry and exit edges of 17009 such a loop, if they lead to/from this region). 17010 17011 * `LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 17012 updated for each loop. This makes some functions (e.g., 17013 `get_loop_exit_edges') more efficient. Some functions (e.g., 17014 `single_exit') can be used only if the lists of exits are recorded. 17015 17016 These properties may also be computed/enforced later, using functions 17017`create_preheaders', `force_single_succ_latches', 17018`mark_irreducible_loops' and `record_loop_exits'. 17019 17020 The memory occupied by the loops structures should be freed with 17021`loop_optimizer_finalize' function. 17022 17023 The CFG manipulation functions in general do not update loop 17024structures. Specialized versions that additionally do so are provided 17025for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function 17026can be used to cleanup CFG while updating the loops structures if 17027`current_loops' is set. 17028 17029 17030File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 17031 1703214.2 Loop querying 17033================== 17034 17035The functions to query the information about loops are declared in 17036`cfgloop.h'. Some of the information can be taken directly from the 17037structures. `loop_father' field of each basic block contains the 17038innermost loop to that the block belongs. The most useful fields of 17039loop structure (that are kept up-to-date at all times) are: 17040 17041 * `header', `latch': Header and latch basic blocks of the loop. 17042 17043 * `num_nodes': Number of basic blocks in the loop (including the 17044 basic blocks of the sub-loops). 17045 17046 * `depth': The depth of the loop in the loops tree, i.e., the number 17047 of super-loops of the loop. 17048 17049 * `outer', `inner', `next': The super-loop, the first sub-loop, and 17050 the sibling of the loop in the loops tree. 17051 17052 There are other fields in the loop structures, many of them used only 17053by some of the passes, or not updated during CFG changes; in general, 17054they should not be accessed directly. 17055 17056 The most important functions to query loop structures are: 17057 17058 * `flow_loops_dump': Dumps the information about loops to a file. 17059 17060 * `verify_loop_structure': Checks consistency of the loop structures. 17061 17062 * `loop_latch_edge': Returns the latch edge of a loop. 17063 17064 * `loop_preheader_edge': If loops have preheaders, returns the 17065 preheader edge of a loop. 17066 17067 * `flow_loop_nested_p': Tests whether loop is a sub-loop of another 17068 loop. 17069 17070 * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a 17071 loop (including its sub-loops). 17072 17073 * `find_common_loop': Finds the common super-loop of two loops. 17074 17075 * `superloop_at_depth': Returns the super-loop of a loop with the 17076 given depth. 17077 17078 * `tree_num_loop_insns', `num_loop_insns': Estimates the number of 17079 insns in the loop, on GIMPLE and on RTL. 17080 17081 * `loop_exit_edge_p': Tests whether edge is an exit from a loop. 17082 17083 * `mark_loop_exit_edges': Marks all exit edges of all loops with 17084 `EDGE_LOOP_EXIT' flag. 17085 17086 * `get_loop_body', `get_loop_body_in_dom_order', 17087 `get_loop_body_in_bfs_order': Enumerates the basic blocks in the 17088 loop in depth-first search order in reversed CFG, ordered by 17089 dominance relation, and breath-first search order, respectively. 17090 17091 * `single_exit': Returns the single exit edge of the loop, or `NULL' 17092 if the loop has more than one exit. You can only use this 17093 function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 17094 17095 * `get_loop_exit_edges': Enumerates the exit edges of a loop. 17096 17097 * `just_once_each_iteration_p': Returns true if the basic block is 17098 executed exactly once during each iteration of a loop (that is, it 17099 does not belong to a sub-loop, and it dominates the latch of the 17100 loop). 17101 17102 17103File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 17104 1710514.3 Loop manipulation 17106====================== 17107 17108The loops tree can be manipulated using the following functions: 17109 17110 * `flow_loop_tree_node_add': Adds a node to the tree. 17111 17112 * `flow_loop_tree_node_remove': Removes a node from the tree. 17113 17114 * `add_bb_to_loop': Adds a basic block to a loop. 17115 17116 * `remove_bb_from_loops': Removes a basic block from loops. 17117 17118 Most low-level CFG functions update loops automatically. The following 17119functions handle some more complicated cases of CFG manipulations: 17120 17121 * `remove_path': Removes an edge and all blocks it dominates. 17122 17123 * `split_loop_exit_edge': Splits exit edge of the loop, ensuring 17124 that PHI node arguments remain in the loop (this ensures that 17125 loop-closed SSA form is preserved). Only useful on GIMPLE. 17126 17127 Finally, there are some higher-level loop transformations implemented. 17128While some of them are written so that they should work on non-innermost 17129loops, they are mostly untested in that case, and at the moment, they 17130are only reliable for the innermost loops: 17131 17132 * `create_iv': Creates a new induction variable. Only works on 17133 GIMPLE. `standard_iv_increment_position' can be used to find a 17134 suitable place for the iv increment. 17135 17136 * `duplicate_loop_to_header_edge', 17137 `tree_duplicate_loop_to_header_edge': These functions (on RTL and 17138 on GIMPLE) duplicate the body of the loop prescribed number of 17139 times on one of the edges entering loop header, thus performing 17140 either loop unrolling or loop peeling. `can_duplicate_loop_p' 17141 (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated 17142 loop. 17143 17144 * `loop_version', `tree_ssa_loop_version': These function create a 17145 copy of a loop, and a branch before them that selects one of them 17146 depending on the prescribed condition. This is useful for 17147 optimizations that need to verify some assumptions in runtime (one 17148 of the copies of the loop is usually left unchanged, while the 17149 other one is transformed in some way). 17150 17151 * `tree_unroll_loop': Unrolls the loop, including peeling the extra 17152 iterations to make the number of iterations divisible by unroll 17153 factor, updating the exit condition, and removing the exits that 17154 now cannot be taken. Works only on GIMPLE. 17155 17156 17157File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 17158 1715914.4 Loop-closed SSA form 17160========================= 17161 17162Throughout the loop optimizations on tree level, one extra condition is 17163enforced on the SSA form: No SSA name is used outside of the loop in 17164that it is defined. The SSA form satisfying this condition is called 17165"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 17166created at the exits of the loops for the SSA names that are used 17167outside of them. Only the real operands (not virtual SSA names) are 17168held in LCSSA, in order to save memory. 17169 17170 There are various benefits of LCSSA: 17171 17172 * Many optimizations (value range analysis, final value replacement) 17173 are interested in the values that are defined in the loop and used 17174 outside of it, i.e., exactly those for that we create new PHI 17175 nodes. 17176 17177 * In induction variable analysis, it is not necessary to specify the 17178 loop in that the analysis should be performed - the scalar 17179 evolution analysis always returns the results with respect to the 17180 loop in that the SSA name is defined. 17181 17182 * It makes updating of SSA form during loop transformations simpler. 17183 Without LCSSA, operations like loop unrolling may force creation 17184 of PHI nodes arbitrarily far from the loop, while in LCSSA, the 17185 SSA form can be updated locally. However, since we only keep real 17186 operands in LCSSA, we cannot use this advantage (we could have 17187 local updating of real operands, but it is not much more efficient 17188 than to use generic SSA form updating for it as well; the amount 17189 of changes to SSA is the same). 17190 17191 However, it also means LCSSA must be updated. This is usually 17192straightforward, unless you create a new value in loop and use it 17193outside, or unless you manipulate loop exit edges (functions are 17194provided to make these manipulations simple). 17195`rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, 17196and `verify_loop_closed_ssa' to check that the invariant of LCSSA is 17197preserved. 17198 17199 17200File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 17201 1720214.5 Scalar evolutions 17203====================== 17204 17205Scalar evolutions (SCEV) are used to represent results of induction 17206variable analysis on GIMPLE. They enable us to represent variables with 17207complicated behavior in a simple and consistent way (we only use it to 17208express values of polynomial induction variables, but it is possible to 17209extend it). The interfaces to SCEV analysis are declared in 17210`tree-scalar-evolution.h'. To use scalar evolutions analysis, 17211`scev_initialize' must be used. To stop using SCEV, `scev_finalize' 17212should be used. SCEV analysis caches results in order to save time and 17213memory. This cache however is made invalid by most of the loop 17214transformations, including removal of code. If such a transformation 17215is performed, `scev_reset' must be called to clean the caches. 17216 17217 Given an SSA name, its behavior in loops can be analyzed using the 17218`analyze_scalar_evolution' function. The returned SCEV however does 17219not have to be fully analyzed and it may contain references to other 17220SSA names defined in the loop. To resolve these (potentially 17221recursive) references, `instantiate_parameters' or `resolve_mixers' 17222functions must be used. `instantiate_parameters' is useful when you 17223use the results of SCEV only for some analysis, and when you work with 17224whole nest of loops at once. It will try replacing all SSA names by 17225their SCEV in all loops, including the super-loops of the current loop, 17226thus providing a complete information about the behavior of the 17227variable in the loop nest. `resolve_mixers' is useful if you work with 17228only one loop at a time, and if you possibly need to create code based 17229on the value of the induction variable. It will only resolve the SSA 17230names defined in the current loop, leaving the SSA names defined 17231outside unchanged, even if their evolution in the outer loops is known. 17232 17233 The SCEV is a normal tree expression, except for the fact that it may 17234contain several special tree nodes. One of them is `SCEV_NOT_KNOWN', 17235used for SSA names whose value cannot be expressed. The other one is 17236`POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 17237and loop (both base and step may contain further polynomial chrecs). 17238Type of the expression and of base and step must be the same. A 17239variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is 17240(in the specified loop) equivalent to `x_1' in the following example 17241 17242 while (...) 17243 { 17244 x_1 = phi (base, x_2); 17245 x_2 = x_1 + step; 17246 } 17247 17248 Note that this includes the language restrictions on the operations. 17249For example, if we compile C code and `x' has signed type, then the 17250overflow in addition would cause undefined behavior, and we may assume 17251that this does not happen. Hence, the value with this SCEV cannot 17252overflow (which restricts the number of iterations of such a loop). 17253 17254 In many cases, one wants to restrict the attention just to affine 17255induction variables. In this case, the extra expressive power of SCEV 17256is not useful, and may complicate the optimizations. In this case, 17257`simple_iv' function may be used to analyze a value - the result is a 17258loop-invariant base and step. 17259 17260 17261File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 17262 1726314.6 IV analysis on RTL 17264======================= 17265 17266The induction variable on RTL is simple and only allows analysis of 17267affine induction variables, and only in one loop at once. The interface 17268is declared in `cfgloop.h'. Before analyzing induction variables in a 17269loop L, `iv_analysis_loop_init' function must be called on L. After 17270the analysis (possibly calling `iv_analysis_loop_init' for several 17271loops) is finished, `iv_analysis_done' should be called. The following 17272functions can be used to access the results of the analysis: 17273 17274 * `iv_analyze': Analyzes a single register used in the given insn. 17275 If no use of the register in this insn is found, the following 17276 insns are scanned, so that this function can be called on the insn 17277 returned by get_condition. 17278 17279 * `iv_analyze_result': Analyzes result of the assignment in the 17280 given insn. 17281 17282 * `iv_analyze_expr': Analyzes a more complicated expression. All 17283 its operands are analyzed by `iv_analyze', and hence they must be 17284 used in the specified insn or one of the following insns. 17285 17286 The description of the induction variable is provided in `struct 17287rtx_iv'. In order to handle subregs, the representation is a bit 17288complicated; if the value of the `extend' field is not `UNKNOWN', the 17289value of the induction variable in the i-th iteration is 17290 17291 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 17292 17293 with the following exception: if `first_special' is true, then the 17294value in the first iteration (when `i' is zero) is `delta + mult * 17295base'. However, if `extend' is equal to `UNKNOWN', then 17296`first_special' must be false, `delta' 0, `mult' 1 and the value in the 17297i-th iteration is 17298 17299 subreg_{mode} (base + i * step) 17300 17301 The function `get_iv_value' can be used to perform these calculations. 17302 17303 17304File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 17305 1730614.7 Number of iterations analysis 17307================================== 17308 17309Both on GIMPLE and on RTL, there are functions available to determine 17310the number of iterations of a loop, with a similar interface. The 17311number of iterations of a loop in GCC is defined as the number of 17312executions of the loop latch. In many cases, it is not possible to 17313determine the number of iterations unconditionally - the determined 17314number is correct only if some assumptions are satisfied. The analysis 17315tries to verify these conditions using the information contained in the 17316program; if it fails, the conditions are returned together with the 17317result. The following information and conditions are provided by the 17318analysis: 17319 17320 * `assumptions': If this condition is false, the rest of the 17321 information is invalid. 17322 17323 * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this 17324 condition is true, the loop exits in the first iteration. 17325 17326 * `infinite': If this condition is true, the loop is infinite. This 17327 condition is only available on RTL. On GIMPLE, conditions for 17328 finiteness of the loop are included in `assumptions'. 17329 17330 * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives 17331 number of iterations. The number of iterations is defined as the 17332 number of executions of the loop latch. 17333 17334 Both on GIMPLE and on RTL, it necessary for the induction variable 17335analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 17336On GIMPLE, the results are stored to `struct tree_niter_desc' 17337structure. Number of iterations before the loop is exited through a 17338given exit can be determined using `number_of_iterations_exit' 17339function. On RTL, the results are returned in `struct niter_desc' 17340structure. The corresponding function is named `check_simple_exit'. 17341There are also functions that pass through all the exits of a loop and 17342try to find one with easy to determine number of iterations - 17343`find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally, 17344there are functions that provide the same information, but additionally 17345cache it, so that repeated calls to number of iterations are not so 17346costly - `number_of_latch_executions' on GIMPLE and 17347`get_simple_loop_desc' on RTL. 17348 17349 Note that some of these functions may behave slightly differently than 17350others - some of them return only the expression for the number of 17351iterations, and fail if there are some assumptions. The function 17352`number_of_latch_executions' works only for single-exit loops. The 17353function `number_of_cond_exit_executions' can be used to determine 17354number of executions of the exit condition of a single-exit loop (i.e., 17355the `number_of_latch_executions' increased by one). 17356 17357 17358File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation 17359 1736014.8 Data Dependency Analysis 17361============================= 17362 17363The code for the data dependence analysis can be found in 17364`tree-data-ref.c' and its interface and data structures are described 17365in `tree-data-ref.h'. The function that computes the data dependences 17366for all the array and pointer references for a given loop is 17367`compute_data_dependences_for_loop'. This function is currently used 17368by the linear loop transform and the vectorization passes. Before 17369calling this function, one has to allocate two vectors: a first vector 17370will contain the set of data references that are contained in the 17371analyzed loop body, and the second vector will contain the dependence 17372relations between the data references. Thus if the vector of data 17373references is of size `n', the vector containing the dependence 17374relations will contain `n*n' elements. However if the analyzed loop 17375contains side effects, such as calls that potentially can interfere 17376with the data references in the current analyzed loop, the analysis 17377stops while scanning the loop body for data references, and inserts a 17378single `chrec_dont_know' in the dependence relation array. 17379 17380 The data references are discovered in a particular order during the 17381scanning of the loop body: the loop body is analyzed in execution order, 17382and the data references of each statement are pushed at the end of the 17383data reference array. Two data references syntactically occur in the 17384program in the same order as in the array of data references. This 17385syntactic order is important in some classical data dependence tests, 17386and mapping this order to the elements of this array avoids costly 17387queries to the loop body representation. 17388 17389 Three types of data references are currently handled: ARRAY_REF, 17390INDIRECT_REF and COMPONENT_REF. The data structure for the data 17391reference is `data_reference', where `data_reference_p' is a name of a 17392pointer to the data reference structure. The structure contains the 17393following elements: 17394 17395 * `base_object_info': Provides information about the base object of 17396 the data reference and its access functions. These access functions 17397 represent the evolution of the data reference in the loop relative 17398 to its base, in keeping with the classical meaning of the data 17399 reference access function for the support of arrays. For example, 17400 for a reference `a.b[i][j]', the base object is `a.b' and the 17401 access functions, one for each array subscript, are: `{i_init, + 17402 i_step}_1, {j_init, +, j_step}_2'. 17403 17404 * `first_location_in_loop': Provides information about the first 17405 location accessed by the data reference in the loop and about the 17406 access function used to represent evolution relative to this 17407 location. This data is used to support pointers, and is not used 17408 for arrays (for which we have base objects). Pointer accesses are 17409 represented as a one-dimensional access that starts from the first 17410 location accessed in the loop. For example: 17411 17412 for1 i 17413 for2 j 17414 *((int *)p + i + j) = a[i][j]; 17415 17416 The access function of the pointer access is `{0, + 4B}_for2' 17417 relative to `p + i'. The access functions of the array are 17418 `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative 17419 to `a'. 17420 17421 Usually, the object the pointer refers to is either unknown, or we 17422 can't prove that the access is confined to the boundaries of a 17423 certain object. 17424 17425 Two data references can be compared only if at least one of these 17426 two representations has all its fields filled for both data 17427 references. 17428 17429 The current strategy for data dependence tests is as follows: If 17430 both `a' and `b' are represented as arrays, compare 17431 `a.base_object' and `b.base_object'; if they are equal, apply 17432 dependence tests (use access functions based on base_objects). 17433 Else if both `a' and `b' are represented as pointers, compare 17434 `a.first_location' and `b.first_location'; if they are equal, 17435 apply dependence tests (use access functions based on first 17436 location). However, if `a' and `b' are represented differently, 17437 only try to prove that the bases are definitely different. 17438 17439 * Aliasing information. 17440 17441 * Alignment information. 17442 17443 The structure describing the relation between two data references is 17444`data_dependence_relation' and the shorter name for a pointer to such a 17445structure is `ddr_p'. This structure contains: 17446 17447 * a pointer to each data reference, 17448 17449 * a tree node `are_dependent' that is set to `chrec_known' if the 17450 analysis has proved that there is no dependence between these two 17451 data references, `chrec_dont_know' if the analysis was not able to 17452 determine any useful result and potentially there could exist a 17453 dependence between these data references, and `are_dependent' is 17454 set to `NULL_TREE' if there exist a dependence relation between the 17455 data references, and the description of this dependence relation is 17456 given in the `subscripts', `dir_vects', and `dist_vects' arrays, 17457 17458 * a boolean that determines whether the dependence relation can be 17459 represented by a classical distance vector, 17460 17461 * an array `subscripts' that contains a description of each 17462 subscript of the data references. Given two array accesses a 17463 subscript is the tuple composed of the access functions for a given 17464 dimension. For example, given `A[f1][f2][f3]' and 17465 `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2), 17466 (f3, g3)'. 17467 17468 * two arrays `dir_vects' and `dist_vects' that contain classical 17469 representations of the data dependences under the form of 17470 direction and distance dependence vectors, 17471 17472 * an array of loops `loop_nest' that contains the loops to which the 17473 distance and direction vectors refer to. 17474 17475 Several functions for pretty printing the information extracted by the 17476data dependence analysis are available: `dump_ddrs' prints with a 17477maximum verbosity the details of a data dependence relations array, 17478`dump_dist_dir_vectors' prints only the classical distance and 17479direction vectors for a data dependence relations array, and 17480`dump_data_references' prints the details of the data references 17481contained in a data reference array. 17482 17483 17484File: gccint.info, Node: Lambda, Next: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation 17485 1748614.9 Linear loop transformations framework 17487========================================== 17488 17489Lambda is a framework that allows transformations of loops using 17490non-singular matrix based transformations of the iteration space and 17491loop bounds. This allows compositions of skewing, scaling, interchange, 17492and reversal transformations. These transformations are often used to 17493improve cache behavior or remove inner loop dependencies to allow 17494parallelization and vectorization to take place. 17495 17496 To perform these transformations, Lambda requires that the loopnest be 17497converted into an internal form that can be matrix transformed easily. 17498To do this conversion, the function `gcc_loopnest_to_lambda_loopnest' 17499is provided. If the loop cannot be transformed using lambda, this 17500function will return NULL. 17501 17502 Once a `lambda_loopnest' is obtained from the conversion function, it 17503can be transformed by using `lambda_loopnest_transform', which takes a 17504transformation matrix to apply. Note that it is up to the caller to 17505verify that the transformation matrix is legal to apply to the loop 17506(dependence respecting, etc). Lambda simply applies whatever matrix it 17507is told to provide. It can be extended to make legal matrices out of 17508any non-singular matrix, but this is not currently implemented. 17509Legality of a matrix for a given loopnest can be verified using 17510`lambda_transform_legal_p'. 17511 17512 Given a transformed loopnest, conversion back into gcc IR is done by 17513`lambda_loopnest_to_gcc_loopnest'. This function will modify the loops 17514so that they match the transformed loopnest. 17515 17516 17517File: gccint.info, Node: Omega, Prev: Lambda, Up: Loop Analysis and Representation 17518 1751914.10 Omega a solver for linear programming problems 17520==================================================== 17521 17522The data dependence analysis contains several solvers triggered 17523sequentially from the less complex ones to the more sophisticated. For 17524ensuring the consistency of the results of these solvers, a data 17525dependence check pass has been implemented based on two different 17526solvers. The second method that has been integrated to GCC is based on 17527the Omega dependence solver, written in the 1990's by William Pugh and 17528David Wonnacott. Data dependence tests can be formulated using a 17529subset of the Presburger arithmetics that can be translated to linear 17530constraint systems. These linear constraint systems can then be solved 17531using the Omega solver. 17532 17533 The Omega solver is using Fourier-Motzkin's algorithm for variable 17534elimination: a linear constraint system containing `n' variables is 17535reduced to a linear constraint system with `n-1' variables. The Omega 17536solver can also be used for solving other problems that can be 17537expressed under the form of a system of linear equalities and 17538inequalities. The Omega solver is known to have an exponential worst 17539case, also known under the name of "omega nightmare" in the literature, 17540but in practice, the omega test is known to be efficient for the common 17541data dependence tests. 17542 17543 The interface used by the Omega solver for describing the linear 17544programming problems is described in `omega.h', and the solver is 17545`omega_solve_problem'. 17546 17547 17548File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 17549 1755015 Control Flow Graph 17551********************* 17552 17553A control flow graph (CFG) is a data structure built on top of the 17554intermediate code representation (the RTL or `GIMPLE' instruction 17555stream) abstracting the control flow behavior of a function that is 17556being compiled. The CFG is a directed graph where the vertices 17557represent basic blocks and edges represent possible transfer of control 17558flow from one basic block to another. The data structures used to 17559represent the control flow graph are defined in `basic-block.h'. 17560 17561 In GCC, the representation of control flow is maintained throughout 17562the compilation process, from constructing the CFG early in 17563`pass_build_cfg' to `pass_free_cfg' (see `passes.c'). The CFG takes 17564various different modes and may undergo extensive manipulations, but 17565the graph is always valid between its construction and its release. 17566This way, transfer of information such as data flow, a measured 17567profile, or the loop tree, can be propagated through the passes 17568pipeline, and even from `GIMPLE' to `RTL'. 17569 17570 Often the CFG may be better viewed as integral part of instruction 17571chain, than structure built on the top of it. Updating the compiler's 17572intermediate representation for instructions can not be easily done 17573without proper maintenance of the CFG simultaneously. 17574 17575* Menu: 17576 17577* Basic Blocks:: The definition and representation of basic blocks. 17578* Edges:: Types of edges and their representation. 17579* Profile information:: Representation of frequencies and probabilities. 17580* Maintaining the CFG:: Keeping the control flow graph and up to date. 17581* Liveness information:: Using and maintaining liveness information. 17582 17583 17584File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 17585 1758615.1 Basic Blocks 17587================= 17588 17589A basic block is a straight-line sequence of code with only one entry 17590point and only one exit. In GCC, basic blocks are represented using 17591the `basic_block' data type. 17592 17593 Special basic blocks represent possible entry and exit points of a 17594function. These blocks are called `ENTRY_BLOCK_PTR' and 17595`EXIT_BLOCK_PTR'. These blocks do not contain any code. 17596 17597 The `BASIC_BLOCK' array contains all basic blocks in an unspecified 17598order. Each `basic_block' structure has a field that holds a unique 17599integer identifier `index' that is the index of the block in the 17600`BASIC_BLOCK' array. The total number of basic blocks in the function 17601is `n_basic_blocks'. Both the basic block indices and the total number 17602of basic blocks may vary during the compilation process, as passes 17603reorder, create, duplicate, and destroy basic blocks. The index for 17604any block should never be greater than `last_basic_block'. The indices 176050 and 1 are special codes reserved for `ENTRY_BLOCK' and `EXIT_BLOCK', 17606the indices of `ENTRY_BLOCK_PTR' and `EXIT_BLOCK_PTR'. 17607 17608 Two pointer members of the `basic_block' structure are the pointers 17609`next_bb' and `prev_bb'. These are used to keep doubly linked chain of 17610basic blocks in the same order as the underlying instruction stream. 17611The chain of basic blocks is updated transparently by the provided API 17612for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit 17613all the basic blocks in lexicographical order, except `ENTRY_BLOCK' and 17614`EXIT_BLOCK'. The macro `FOR_ALL_BB' also visits all basic blocks in 17615lexicographical order, including `ENTRY_BLOCK' and `EXIT_BLOCK'. 17616 17617 The functions `post_order_compute' and `inverted_post_order_compute' 17618can be used to compute topological orders of the CFG. The orders are 17619stored as vectors of basic block indices. The `BASIC_BLOCK' array can 17620be used to iterate each basic block by index. Dominator traversals are 17621also possible using `walk_dominator_tree'. Given two basic blocks A 17622and B, block A dominates block B if A is _always_ executed before B. 17623 17624 Each `basic_block' also contains pointers to the first instruction 17625(the "head") and the last instruction (the "tail") or "end" of the 17626instruction stream contained in a basic block. In fact, since the 17627`basic_block' data type is used to represent blocks in both major 17628intermediate representations of GCC (`GIMPLE' and RTL), there are 17629pointers to the head and end of a basic block for both representations, 17630stored in intermediate representation specific data in the `il' field 17631of `struct basic_block_def'. 17632 17633 For RTL, these pointers are `BB_HEAD' and `BB_END'. 17634 17635 In the RTL representation of a function, the instruction stream 17636contains not only the "real" instructions, but also "notes" or "insn 17637notes" (to distinguish them from "reg notes"). Any function that moves 17638or duplicates the basic blocks needs to take care of updating of these 17639notes. Many of these notes expect that the instruction stream consists 17640of linear regions, so updating can sometimes be tedious. All types of 17641insn notes are defined in `insn-notes.def'. 17642 17643 In the RTL function representation, the instructions contained in a 17644basic block always follow a `NOTE_INSN_BASIC_BLOCK', but zero or more 17645`CODE_LABEL' nodes can precede the block note. A basic block ends with 17646a control flow instruction or with the last instruction before the next 17647`CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. By definition, a `CODE_LABEL' 17648cannot appear in the middle of the instruction stream of a basic block. 17649 17650 In addition to notes, the jump table vectors are also represented as 17651"pseudo-instructions" inside the insn stream. These vectors never 17652appear in the basic block and should always be placed just after the 17653table jump instructions referencing them. After removing the 17654table-jump it is often difficult to eliminate the code computing the 17655address and referencing the vector, so cleaning up these vectors is 17656postponed until after liveness analysis. Thus the jump table vectors 17657may appear in the insn stream unreferenced and without any purpose. 17658Before any edge is made "fall-thru", the existence of such construct in 17659the way needs to be checked by calling `can_fallthru' function. 17660 17661 For the `GIMPLE' representation, the PHI nodes and statements 17662contained in a basic block are in a `gimple_seq' pointed to by the 17663basic block intermediate language specific pointers. Abstract 17664containers and iterators are used to access the PHI nodes and 17665statements in a basic blocks. These iterators are called "GIMPLE 17666statement iterators" (GSIs). Grep for `^gsi' in the various `gimple-*' 17667and `tree-*' files. The following snippet will pretty-print all PHI 17668nodes the statements of the current function in the GIMPLE 17669representation. 17670 17671 basic_block bb; 17672 17673 FOR_EACH_BB (bb) 17674 { 17675 gimple_stmt_iterator si; 17676 17677 for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si)) 17678 { 17679 gimple phi = gsi_stmt (si); 17680 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 17681 } 17682 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 17683 { 17684 gimple stmt = gsi_stmt (si); 17685 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 17686 } 17687 } 17688 17689 17690File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 17691 1769215.2 Edges 17693========== 17694 17695Edges represent possible control flow transfers from the end of some 17696basic block A to the head of another basic block B. We say that A is a 17697predecessor of B, and B is a successor of A. Edges are represented in 17698GCC with the `edge' data type. Each `edge' acts as a link between two 17699basic blocks: The `src' member of an edge points to the predecessor 17700basic block of the `dest' basic block. The members `preds' and `succs' 17701of the `basic_block' data type point to type-safe vectors of edges to 17702the predecessors and successors of the block. 17703 17704 When walking the edges in an edge vector, "edge iterators" should be 17705used. Edge iterators are constructed using the `edge_iterator' data 17706structure and several methods are available to operate on them: 17707 17708`ei_start' 17709 This function initializes an `edge_iterator' that points to the 17710 first edge in a vector of edges. 17711 17712`ei_last' 17713 This function initializes an `edge_iterator' that points to the 17714 last edge in a vector of edges. 17715 17716`ei_end_p' 17717 This predicate is `true' if an `edge_iterator' represents the last 17718 edge in an edge vector. 17719 17720`ei_one_before_end_p' 17721 This predicate is `true' if an `edge_iterator' represents the 17722 second last edge in an edge vector. 17723 17724`ei_next' 17725 This function takes a pointer to an `edge_iterator' and makes it 17726 point to the next edge in the sequence. 17727 17728`ei_prev' 17729 This function takes a pointer to an `edge_iterator' and makes it 17730 point to the previous edge in the sequence. 17731 17732`ei_edge' 17733 This function returns the `edge' currently pointed to by an 17734 `edge_iterator'. 17735 17736`ei_safe_safe' 17737 This function returns the `edge' currently pointed to by an 17738 `edge_iterator', but returns `NULL' if the iterator is pointing at 17739 the end of the sequence. This function has been provided for 17740 existing code makes the assumption that a `NULL' edge indicates 17741 the end of the sequence. 17742 17743 17744 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the 17745edges in a sequence of predecessor or successor edges. It must not be 17746used when an element might be removed during the traversal, otherwise 17747elements will be missed. Here is an example of how to use the macro: 17748 17749 edge e; 17750 edge_iterator ei; 17751 17752 FOR_EACH_EDGE (e, ei, bb->succs) 17753 { 17754 if (e->flags & EDGE_FALLTHRU) 17755 break; 17756 } 17757 17758 There are various reasons why control flow may transfer from one block 17759to another. One possibility is that some instruction, for example a 17760`CODE_LABEL', in a linearized instruction stream just always starts a 17761new basic block. In this case a "fall-thru" edge links the basic block 17762to the first following basic block. But there are several other 17763reasons why edges may be created. The `flags' field of the `edge' data 17764type is used to store information about the type of edge we are dealing 17765with. Each edge is of one of the following types: 17766 17767_jump_ 17768 No type flags are set for edges corresponding to jump instructions. 17769 These edges are used for unconditional or conditional jumps and in 17770 RTL also for table jumps. They are the easiest to manipulate as 17771 they may be freely redirected when the flow graph is not in SSA 17772 form. 17773 17774_fall-thru_ 17775 Fall-thru edges are present in case where the basic block may 17776 continue execution to the following one without branching. These 17777 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of 17778 edges, these edges must come into the basic block immediately 17779 following in the instruction stream. The function 17780 `force_nonfallthru' is available to insert an unconditional jump 17781 in the case that redirection is needed. Note that this may 17782 require creation of a new basic block. 17783 17784_exception handling_ 17785 Exception handling edges represent possible control transfers from 17786 a trapping instruction to an exception handler. The definition of 17787 "trapping" varies. In C++, only function calls can throw, but for 17788 Java and Ada, exceptions like division by zero or segmentation 17789 fault are defined and thus each instruction possibly throwing this 17790 kind of exception needs to be handled as control flow instruction. 17791 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set. 17792 17793 When updating the instruction stream it is easy to change possibly 17794 trapping instruction to non-trapping, by simply removing the 17795 exception edge. The opposite conversion is difficult, but should 17796 not happen anyway. The edges can be eliminated via 17797 `purge_dead_edges' call. 17798 17799 In the RTL representation, the destination of an exception edge is 17800 specified by `REG_EH_REGION' note attached to the insn. In case 17801 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In 17802 the `GIMPLE' representation, this extra flag is not set. 17803 17804 In the RTL representation, the predicate `may_trap_p' may be used 17805 to check whether instruction still may trap or not. For the tree 17806 representation, the `tree_could_trap_p' predicate is available, 17807 but this predicate only checks for possible memory traps, as in 17808 dereferencing an invalid pointer location. 17809 17810_sibling calls_ 17811 Sibling calls or tail calls terminate the function in a 17812 non-standard way and thus an edge to the exit must be present. 17813 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These 17814 edges only exist in the RTL representation. 17815 17816_computed jumps_ 17817 Computed jumps contain edges to all labels in the function 17818 referenced from the code. All those edges have `EDGE_ABNORMAL' 17819 flag set. The edges used to represent computed jumps often cause 17820 compile time performance problems, since functions consisting of 17821 many taken labels and many computed jumps may have _very_ dense 17822 flow graphs, so these edges need to be handled with special care. 17823 During the earlier stages of the compilation process, GCC tries to 17824 avoid such dense flow graphs by factoring computed jumps. For 17825 example, given the following series of jumps, 17826 17827 goto *x; 17828 [ ... ] 17829 17830 goto *x; 17831 [ ... ] 17832 17833 goto *x; 17834 [ ... ] 17835 17836 factoring the computed jumps results in the following code sequence 17837 which has a much simpler flow graph: 17838 17839 goto y; 17840 [ ... ] 17841 17842 goto y; 17843 [ ... ] 17844 17845 goto y; 17846 [ ... ] 17847 17848 y: 17849 goto *x; 17850 17851 However, the classic problem with this transformation is that it 17852 has a runtime cost in there resulting code: An extra jump. 17853 Therefore, the computed jumps are un-factored in the later passes 17854 of the compiler (in the pass called 17855 `pass_duplicate_computed_gotos'). Be aware of that when you work 17856 on passes in that area. There have been numerous examples already 17857 where the compile time for code with unfactored computed jumps 17858 caused some serious headaches. 17859 17860_nonlocal goto handlers_ 17861 GCC allows nested functions to return into caller using a `goto' 17862 to a label passed to as an argument to the callee. The labels 17863 passed to nested functions contain special code to cleanup after 17864 function call. Such sections of code are referred to as "nonlocal 17865 goto receivers". If a function contains such nonlocal goto 17866 receivers, an edge from the call to the label is created with the 17867 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set. 17868 17869_function entry points_ 17870 By definition, execution of function starts at basic block 0, so 17871 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block 17872 0. There is no `GIMPLE' representation for alternate entry points 17873 at this moment. In RTL, alternate entry points are specified by 17874 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is 17875 currently used for multiple entry point prologues and is limited 17876 to post-reload passes only. This can be used by back-ends to emit 17877 alternate prologues for functions called from different contexts. 17878 In future full support for multiple entry functions defined by 17879 Fortran 90 needs to be implemented. 17880 17881_function exits_ 17882 In the pre-reload representation a function terminates after the 17883 last instruction in the insn chain and no explicit return 17884 instructions are used. This corresponds to the fall-thru edge 17885 into exit block. After reload, optimal RTL epilogues are used 17886 that use explicit (conditional) return instructions that are 17887 represented by edges with no flags set. 17888 17889 17890 17891File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 17892 1789315.3 Profile information 17894======================== 17895 17896In many cases a compiler must make a choice whether to trade speed in 17897one part of code for speed in another, or to trade code size for code 17898speed. In such cases it is useful to know information about how often 17899some given block will be executed. That is the purpose for maintaining 17900profile within the flow graph. GCC can handle profile information 17901obtained through "profile feedback", but it can also estimate branch 17902probabilities based on statics and heuristics. 17903 17904 The feedback based profile is produced by compiling the program with 17905instrumentation, executing it on a train run and reading the numbers of 17906executions of basic blocks and edges back to the compiler while 17907re-compiling the program to produce the final executable. This method 17908provides very accurate information about where a program spends most of 17909its time on the train run. Whether it matches the average run of 17910course depends on the choice of train data set, but several studies 17911have shown that the behavior of a program usually changes just 17912marginally over different data sets. 17913 17914 When profile feedback is not available, the compiler may be asked to 17915attempt to predict the behavior of each branch in the program using a 17916set of heuristics (see `predict.def' for details) and compute estimated 17917frequencies of each basic block by propagating the probabilities over 17918the graph. 17919 17920 Each `basic_block' contains two integer fields to represent profile 17921information: `frequency' and `count'. The `frequency' is an estimation 17922how often is basic block executed within a function. It is represented 17923as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most 17924frequently executed basic block in function is initially set to 17925`BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 17926During optimization, the frequency of the most frequent basic block can 17927both decrease (for instance by loop unrolling) or grow (for instance by 17928cross-jumping optimization), so scaling sometimes has to be performed 17929multiple times. 17930 17931 The `count' contains hard-counted numbers of execution measured during 17932training runs and is nonzero only when profile feedback is available. 17933This value is represented as the host's widest integer (typically a 64 17934bit integer) of the special type `gcov_type'. 17935 17936 Most optimization passes can use only the frequency information of a 17937basic block, but a few passes may want to know hard execution counts. 17938The frequencies should always match the counts after scaling, however 17939during updating of the profile information numerical error may 17940accumulate into quite large errors. 17941 17942 Each edge also contains a branch probability field: an integer in the 17943range from 0 to `REG_BR_PROB_BASE'. It represents probability of 17944passing control from the end of the `src' basic block to the `dest' 17945basic block, i.e. the probability that control will flow along this 17946edge. The `EDGE_FREQUENCY' macro is available to compute how 17947frequently a given edge is taken. There is a `count' field for each 17948edge as well, representing same information as for a basic block. 17949 17950 The basic block frequencies are not represented in the instruction 17951stream, but in the RTL representation the edge frequencies are 17952represented for conditional jumps (via the `REG_BR_PROB' macro) since 17953they are used when instructions are output to the assembly file and the 17954flow graph is no longer maintained. 17955 17956 The probability that control flow arrives via a given edge to its 17957destination basic block is called "reverse probability" and is not 17958directly represented, but it may be easily computed from frequencies of 17959basic blocks. 17960 17961 Updating profile information is a delicate task that can unfortunately 17962not be easily integrated with the CFG manipulation API. Many of the 17963functions and hooks to modify the CFG, such as 17964`redirect_edge_and_branch', do not have enough information to easily 17965update the profile, so updating it is in the majority of cases left up 17966to the caller. It is difficult to uncover bugs in the profile updating 17967code, because they manifest themselves only by producing worse code, 17968and checking profile consistency is not possible because of numeric 17969error accumulation. Hence special attention needs to be given to this 17970issue in each pass that modifies the CFG. 17971 17972 It is important to point out that `REG_BR_PROB_BASE' and 17973`BB_FREQ_BASE' are both set low enough to be possible to compute second 17974power of any frequency or probability in the flow graph, it is not 17975possible to even square the `count' field, as modern CPUs are fast 17976enough to execute $2^32$ operations quickly. 17977 17978 17979File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 17980 1798115.4 Maintaining the CFG 17982======================== 17983 17984An important task of each compiler pass is to keep both the control 17985flow graph and all profile information up-to-date. Reconstruction of 17986the control flow graph after each pass is not an option, since it may be 17987very expensive and lost profile information cannot be reconstructed at 17988all. 17989 17990 GCC has two major intermediate representations, and both use the 17991`basic_block' and `edge' data types to represent control flow. Both 17992representations share as much of the CFG maintenance code as possible. 17993For each representation, a set of "hooks" is defined so that each 17994representation can provide its own implementation of CFG manipulation 17995routines when necessary. These hooks are defined in `cfghooks.h'. 17996There are hooks for almost all common CFG manipulations, including 17997block splitting and merging, edge redirection and creating and deleting 17998basic blocks. These hooks should provide everything you need to 17999maintain and manipulate the CFG in both the RTL and `GIMPLE' 18000representation. 18001 18002 At the moment, the basic block boundaries are maintained transparently 18003when modifying instructions, so there rarely is a need to move them 18004manually (such as in case someone wants to output instruction outside 18005basic block explicitly). 18006 18007 In the RTL representation, each instruction has a `BLOCK_FOR_INSN' 18008value that represents pointer to the basic block that contains the 18009instruction. In the `GIMPLE' representation, the function `gimple_bb' 18010returns a pointer to the basic block containing the queried statement. 18011 18012 When changes need to be applied to a function in its `GIMPLE' 18013representation, "GIMPLE statement iterators" should be used. These 18014iterators provide an integrated abstraction of the flow graph and the 18015instruction stream. Block statement iterators are constructed using 18016the `gimple_stmt_iterator' data structure and several modifier are 18017available, including the following: 18018 18019`gsi_start' 18020 This function initializes a `gimple_stmt_iterator' that points to 18021 the first non-empty statement in a basic block. 18022 18023`gsi_last' 18024 This function initializes a `gimple_stmt_iterator' that points to 18025 the last statement in a basic block. 18026 18027`gsi_end_p' 18028 This predicate is `true' if a `gimple_stmt_iterator' represents 18029 the end of a basic block. 18030 18031`gsi_next' 18032 This function takes a `gimple_stmt_iterator' and makes it point to 18033 its successor. 18034 18035`gsi_prev' 18036 This function takes a `gimple_stmt_iterator' and makes it point to 18037 its predecessor. 18038 18039`gsi_insert_after' 18040 This function inserts a statement after the `gimple_stmt_iterator' 18041 passed in. The final parameter determines whether the statement 18042 iterator is updated to point to the newly inserted statement, or 18043 left pointing to the original statement. 18044 18045`gsi_insert_before' 18046 This function inserts a statement before the `gimple_stmt_iterator' 18047 passed in. The final parameter determines whether the statement 18048 iterator is updated to point to the newly inserted statement, or 18049 left pointing to the original statement. 18050 18051`gsi_remove' 18052 This function removes the `gimple_stmt_iterator' passed in and 18053 rechains the remaining statements in a basic block, if any. 18054 18055 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be 18056used to get the head and end `rtx' of a basic block. No abstract 18057iterators are defined for traversing the insn chain, but you can just 18058use `NEXT_INSN' and `PREV_INSN' instead. *Note Insns::. 18059 18060 Usually a code manipulating pass simplifies the instruction stream and 18061the flow of control, possibly eliminating some edges. This may for 18062example happen when a conditional jump is replaced with an 18063unconditional jump, but also when simplifying possibly trapping 18064instruction to non-trapping while compiling Java. Updating of edges is 18065not transparent and each optimization pass is required to do so 18066manually. However only few cases occur in practice. The pass may call 18067`purge_dead_edges' on a given basic block to remove superfluous edges, 18068if any. 18069 18070 Another common scenario is redirection of branch instructions, but 18071this is best modeled as redirection of edges in the control flow graph 18072and thus use of `redirect_edge_and_branch' is preferred over more low 18073level functions, such as `redirect_jump' that operate on RTL chain 18074only. The CFG hooks defined in `cfghooks.h' should provide the 18075complete API required for manipulating and maintaining the CFG. 18076 18077 It is also possible that a pass has to insert control flow instruction 18078into the middle of a basic block, thus creating an entry point in the 18079middle of the basic block, which is impossible by definition: The block 18080must be split to make sure it only has one entry point, i.e. the head 18081of the basic block. The CFG hook `split_block' may be used when an 18082instruction in the middle of a basic block has to become the target of 18083a jump or branch instruction. 18084 18085 For a global optimizer, a common operation is to split edges in the 18086flow graph and insert instructions on them. In the RTL representation, 18087this can be easily done using the `insert_insn_on_edge' function that 18088emits an instruction "on the edge", caching it for a later 18089`commit_edge_insertions' call that will take care of moving the 18090inserted instructions off the edge into the instruction stream 18091contained in a basic block. This includes the creation of new basic 18092blocks where needed. In the `GIMPLE' representation, the equivalent 18093functions are `gsi_insert_on_edge' which inserts a block statement 18094iterator on an edge, and `gsi_commit_edge_inserts' which flushes the 18095instruction to actual instruction stream. 18096 18097 While debugging the optimization pass, the `verify_flow_info' function 18098may be useful to find bugs in the control flow graph updating code. 18099 18100 18101File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 18102 1810315.5 Liveness information 18104========================= 18105 18106Liveness information is useful to determine whether some register is 18107"live" at given point of program, i.e. that it contains a value that 18108may be used at a later point in the program. This information is used, 18109for instance, during register allocation, as the pseudo registers only 18110need to be assigned to a unique hard register or to a stack slot if 18111they are live. The hard registers and stack slots may be freely reused 18112for other values when a register is dead. 18113 18114 Liveness information is available in the back end starting with 18115`pass_df_initialize' and ending with `pass_df_finish'. Three flavors 18116of live analysis are available: With `LR', it is possible to determine 18117at any point `P' in the function if the register may be used on some 18118path from `P' to the end of the function. With `UR', it is possible to 18119determine if there is a path from the beginning of the function to `P' 18120that defines the variable. `LIVE' is the intersection of the `LR' and 18121`UR' and a variable is live at `P' if there is both an assignment that 18122reaches it from the beginning of the function and a use that can be 18123reached on some path from `P' to the end of the function. 18124 18125 In general `LIVE' is the most useful of the three. The macros 18126`DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 18127macros take a basic block number and return a bitmap that is indexed by 18128the register number. This information is only guaranteed to be up to 18129date after calls are made to `df_analyze'. See the file `df-core.c' 18130for details on using the dataflow. 18131 18132 The liveness information is stored partly in the RTL instruction stream 18133and partly in the flow graph. Local information is stored in the 18134instruction stream: Each instruction may contain `REG_DEAD' notes 18135representing that the value of a given register is no longer needed, or 18136`REG_UNUSED' notes representing that the value computed by the 18137instruction is never used. The second is useful for instructions 18138computing multiple values at once. 18139 18140 18141File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 18142 1814316 Machine Descriptions 18144*********************** 18145 18146A machine description has two parts: a file of instruction patterns 18147(`.md' file) and a C header file of macro definitions. 18148 18149 The `.md' file for a target machine contains a pattern for each 18150instruction that the target machine supports (or at least each 18151instruction that is worth telling the compiler about). It may also 18152contain comments. A semicolon causes the rest of the line to be a 18153comment, unless the semicolon is inside a quoted string. 18154 18155 See the next chapter for information on the C header file. 18156 18157* Menu: 18158 18159* Overview:: How the machine description is used. 18160* Patterns:: How to write instruction patterns. 18161* Example:: An explained example of a `define_insn' pattern. 18162* RTL Template:: The RTL template defines what insns match a pattern. 18163* Output Template:: The output template says how to make assembler code 18164 from such an insn. 18165* Output Statement:: For more generality, write C code to output 18166 the assembler code. 18167* Predicates:: Controlling what kinds of operands can be used 18168 for an insn. 18169* Constraints:: Fine-tuning operand selection. 18170* Standard Names:: Names mark patterns to use for code generation. 18171* Pattern Ordering:: When the order of patterns makes a difference. 18172* Dependent Patterns:: Having one pattern may make you need another. 18173* Jump Patterns:: Special considerations for patterns for jump insns. 18174* Looping Patterns:: How to define patterns for special looping insns. 18175* Insn Canonicalizations::Canonicalization of Instructions 18176* Expander Definitions::Generating a sequence of several RTL insns 18177 for a standard operation. 18178* Insn Splitting:: Splitting Instructions into Multiple Instructions. 18179* Including Patterns:: Including Patterns in Machine Descriptions. 18180* Peephole Definitions::Defining machine-specific peephole optimizations. 18181* Insn Attributes:: Specifying the value of attributes for generated insns. 18182* Conditional Execution::Generating `define_insn' patterns for 18183 predication. 18184* Define Subst:: Generating `define_insn' and `define_expand' 18185 patterns from other patterns. 18186* Constant Definitions::Defining symbolic constants that can be used in the 18187 md file. 18188* Iterators:: Using iterators to generate patterns from a template. 18189 18190 18191File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 18192 1819316.1 Overview of How the Machine Description is Used 18194==================================================== 18195 18196There are three main conversions that happen in the compiler: 18197 18198 1. The front end reads the source code and builds a parse tree. 18199 18200 2. The parse tree is used to generate an RTL insn list based on named 18201 instruction patterns. 18202 18203 3. The insn list is matched against the RTL templates to produce 18204 assembler code. 18205 18206 18207 For the generate pass, only the names of the insns matter, from either 18208a named `define_insn' or a `define_expand'. The compiler will choose 18209the pattern with the right name and apply the operands according to the 18210documentation later in this chapter, without regard for the RTL 18211template or operand constraints. Note that the names the compiler looks 18212for are hard-coded in the compiler--it will ignore unnamed patterns and 18213patterns with names it doesn't know about, but if you don't provide a 18214named pattern it needs, it will abort. 18215 18216 If a `define_insn' is used, the template given is inserted into the 18217insn list. If a `define_expand' is used, one of three things happens, 18218based on the condition logic. The condition logic may manually create 18219new insns for the insn list, say via `emit_insn()', and invoke `DONE'. 18220For certain named patterns, it may invoke `FAIL' to tell the compiler 18221to use an alternate way of performing that task. If it invokes neither 18222`DONE' nor `FAIL', the template given in the pattern is inserted, as if 18223the `define_expand' were a `define_insn'. 18224 18225 Once the insn list is generated, various optimization passes convert, 18226replace, and rearrange the insns in the insn list. This is where the 18227`define_split' and `define_peephole' patterns get used, for example. 18228 18229 Finally, the insn list's RTL is matched up with the RTL templates in 18230the `define_insn' patterns, and those patterns are used to emit the 18231final assembly code. For this purpose, each named `define_insn' acts 18232like it's unnamed, since the names are ignored. 18233 18234 18235File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 18236 1823716.2 Everything about Instruction Patterns 18238========================================== 18239 18240Each instruction pattern contains an incomplete RTL expression, with 18241pieces to be filled in later, operand constraints that restrict how the 18242pieces can be filled in, and an output pattern or C code to generate 18243the assembler output, all wrapped up in a `define_insn' expression. 18244 18245 A `define_insn' is an RTL expression containing four or five operands: 18246 18247 1. An optional name. The presence of a name indicate that this 18248 instruction pattern can perform a certain standard job for the 18249 RTL-generation pass of the compiler. This pass knows certain 18250 names and will use the instruction patterns with those names, if 18251 the names are defined in the machine description. 18252 18253 The absence of a name is indicated by writing an empty string 18254 where the name should go. Nameless instruction patterns are never 18255 used for generating RTL code, but they may permit several simpler 18256 insns to be combined later on. 18257 18258 Names that are not thus known and used in RTL-generation have no 18259 effect; they are equivalent to no name at all. 18260 18261 For the purpose of debugging the compiler, you may also specify a 18262 name beginning with the `*' character. Such a name is used only 18263 for identifying the instruction in RTL dumps; it is entirely 18264 equivalent to having a nameless pattern for all other purposes. 18265 18266 2. The "RTL template" (*note RTL Template::) is a vector of incomplete 18267 RTL expressions which show what the instruction should look like. 18268 It is incomplete because it may contain `match_operand', 18269 `match_operator', and `match_dup' expressions that stand for 18270 operands of the instruction. 18271 18272 If the vector has only one element, that element is the template 18273 for the instruction pattern. If the vector has multiple elements, 18274 then the instruction pattern is a `parallel' expression containing 18275 the elements described. 18276 18277 3. A condition. This is a string which contains a C expression that 18278 is the final test to decide whether an insn body matches this 18279 pattern. 18280 18281 For a named pattern, the condition (if present) may not depend on 18282 the data in the insn being matched, but only the 18283 target-machine-type flags. The compiler needs to test these 18284 conditions during initialization in order to learn exactly which 18285 named instructions are available in a particular run. 18286 18287 For nameless patterns, the condition is applied only when matching 18288 an individual insn, and only after the insn has matched the 18289 pattern's recognition template. The insn's operands may be found 18290 in the vector `operands'. For an insn where the condition has 18291 once matched, it can't be used to control register allocation, for 18292 example by excluding certain hard registers or hard register 18293 combinations. 18294 18295 4. The "output template": a string that says how to output matching 18296 insns as assembler code. `%' in this string specifies where to 18297 substitute the value of an operand. *Note Output Template::. 18298 18299 When simple substitution isn't general enough, you can specify a 18300 piece of C code to compute the output. *Note Output Statement::. 18301 18302 5. Optionally, a vector containing the values of attributes for insns 18303 matching this pattern. *Note Insn Attributes::. 18304 18305 18306File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 18307 1830816.3 Example of `define_insn' 18309============================= 18310 18311Here is an actual example of an instruction pattern, for the 1831268000/68020. 18313 18314 (define_insn "tstsi" 18315 [(set (cc0) 18316 (match_operand:SI 0 "general_operand" "rm"))] 18317 "" 18318 "* 18319 { 18320 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18321 return \"tstl %0\"; 18322 return \"cmpl #0,%0\"; 18323 }") 18324 18325This can also be written using braced strings: 18326 18327 (define_insn "tstsi" 18328 [(set (cc0) 18329 (match_operand:SI 0 "general_operand" "rm"))] 18330 "" 18331 { 18332 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18333 return "tstl %0"; 18334 return "cmpl #0,%0"; 18335 }) 18336 18337 This is an instruction that sets the condition codes based on the 18338value of a general operand. It has no condition, so any insn whose RTL 18339description has the form shown may be handled according to this 18340pattern. The name `tstsi' means "test a `SImode' value" and tells the 18341RTL generation pass that, when it is necessary to test such a value, an 18342insn to do so can be constructed using this pattern. 18343 18344 The output control string is a piece of C code which chooses which 18345output template to return based on the kind of operand and the specific 18346type of CPU for which code is being generated. 18347 18348 `"rm"' is an operand constraint. Its meaning is explained below. 18349 18350 18351File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 18352 1835316.4 RTL Template 18354================= 18355 18356The RTL template is used to define which insns match the particular 18357pattern and how to find their operands. For named patterns, the RTL 18358template also says how to construct an insn from specified operands. 18359 18360 Construction involves substituting specified operands into a copy of 18361the template. Matching involves determining the values that serve as 18362the operands in the insn being matched. Both of these activities are 18363controlled by special expression types that direct matching and 18364substitution of the operands. 18365 18366`(match_operand:M N PREDICATE CONSTRAINT)' 18367 This expression is a placeholder for operand number N of the insn. 18368 When constructing an insn, operand number N will be substituted at 18369 this point. When matching an insn, whatever appears at this 18370 position in the insn will be taken as operand number N; but it 18371 must satisfy PREDICATE or this instruction pattern will not match 18372 at all. 18373 18374 Operand numbers must be chosen consecutively counting from zero in 18375 each instruction pattern. There may be only one `match_operand' 18376 expression in the pattern for each operand number. Usually 18377 operands are numbered in the order of appearance in `match_operand' 18378 expressions. In the case of a `define_expand', any operand numbers 18379 used only in `match_dup' expressions have higher values than all 18380 other operand numbers. 18381 18382 PREDICATE is a string that is the name of a function that accepts 18383 two arguments, an expression and a machine mode. *Note 18384 Predicates::. During matching, the function will be called with 18385 the putative operand as the expression and M as the mode argument 18386 (if M is not specified, `VOIDmode' will be used, which normally 18387 causes PREDICATE to accept any mode). If it returns zero, this 18388 instruction pattern fails to match. PREDICATE may be an empty 18389 string; then it means no test is to be done on the operand, so 18390 anything which occurs in this position is valid. 18391 18392 Most of the time, PREDICATE will reject modes other than M--but 18393 not always. For example, the predicate `address_operand' uses M 18394 as the mode of memory ref that the address should be valid for. 18395 Many predicates accept `const_int' nodes even though their mode is 18396 `VOIDmode'. 18397 18398 CONSTRAINT controls reloading and the choice of the best register 18399 class to use for a value, as explained later (*note Constraints::). 18400 If the constraint would be an empty string, it can be omitted. 18401 18402 People are often unclear on the difference between the constraint 18403 and the predicate. The predicate helps decide whether a given 18404 insn matches the pattern. The constraint plays no role in this 18405 decision; instead, it controls various decisions in the case of an 18406 insn which does match. 18407 18408`(match_scratch:M N CONSTRAINT)' 18409 This expression is also a placeholder for operand number N and 18410 indicates that operand must be a `scratch' or `reg' expression. 18411 18412 When matching patterns, this is equivalent to 18413 18414 (match_operand:M N "scratch_operand" PRED) 18415 18416 but, when generating RTL, it produces a (`scratch':M) expression. 18417 18418 If the last few expressions in a `parallel' are `clobber' 18419 expressions whose operands are either a hard register or 18420 `match_scratch', the combiner can add or delete them when 18421 necessary. *Note Side Effects::. 18422 18423`(match_dup N)' 18424 This expression is also a placeholder for operand number N. It is 18425 used when the operand needs to appear more than once in the insn. 18426 18427 In construction, `match_dup' acts just like `match_operand': the 18428 operand is substituted into the insn being constructed. But in 18429 matching, `match_dup' behaves differently. It assumes that operand 18430 number N has already been determined by a `match_operand' 18431 appearing earlier in the recognition template, and it matches only 18432 an identical-looking expression. 18433 18434 Note that `match_dup' should not be used to tell the compiler that 18435 a particular register is being used for two operands (example: 18436 `add' that adds one register to another; the second register is 18437 both an input operand and the output operand). Use a matching 18438 constraint (*note Simple Constraints::) for those. `match_dup' is 18439 for the cases where one operand is used in two places in the 18440 template, such as an instruction that computes both a quotient and 18441 a remainder, where the opcode takes two input operands but the RTL 18442 template has to refer to each of those twice; once for the 18443 quotient pattern and once for the remainder pattern. 18444 18445`(match_operator:M N PREDICATE [OPERANDS...])' 18446 This pattern is a kind of placeholder for a variable RTL expression 18447 code. 18448 18449 When constructing an insn, it stands for an RTL expression whose 18450 expression code is taken from that of operand N, and whose 18451 operands are constructed from the patterns OPERANDS. 18452 18453 When matching an expression, it matches an expression if the 18454 function PREDICATE returns nonzero on that expression _and_ the 18455 patterns OPERANDS match the operands of the expression. 18456 18457 Suppose that the function `commutative_operator' is defined as 18458 follows, to match any expression whose operator is one of the 18459 commutative arithmetic operators of RTL and whose mode is MODE: 18460 18461 int 18462 commutative_integer_operator (x, mode) 18463 rtx x; 18464 enum machine_mode mode; 18465 { 18466 enum rtx_code code = GET_CODE (x); 18467 if (GET_MODE (x) != mode) 18468 return 0; 18469 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 18470 || code == EQ || code == NE); 18471 } 18472 18473 Then the following pattern will match any RTL expression consisting 18474 of a commutative operator applied to two general operands: 18475 18476 (match_operator:SI 3 "commutative_operator" 18477 [(match_operand:SI 1 "general_operand" "g") 18478 (match_operand:SI 2 "general_operand" "g")]) 18479 18480 Here the vector `[OPERANDS...]' contains two patterns because the 18481 expressions to be matched all contain two operands. 18482 18483 When this pattern does match, the two operands of the commutative 18484 operator are recorded as operands 1 and 2 of the insn. (This is 18485 done by the two instances of `match_operand'.) Operand 3 of the 18486 insn will be the entire commutative expression: use `GET_CODE 18487 (operands[3])' to see which commutative operator was used. 18488 18489 The machine mode M of `match_operator' works like that of 18490 `match_operand': it is passed as the second argument to the 18491 predicate function, and that function is solely responsible for 18492 deciding whether the expression to be matched "has" that mode. 18493 18494 When constructing an insn, argument 3 of the gen-function will 18495 specify the operation (i.e. the expression code) for the 18496 expression to be made. It should be an RTL expression, whose 18497 expression code is copied into a new expression whose operands are 18498 arguments 1 and 2 of the gen-function. The subexpressions of 18499 argument 3 are not used; only its expression code matters. 18500 18501 When `match_operator' is used in a pattern for matching an insn, 18502 it usually best if the operand number of the `match_operator' is 18503 higher than that of the actual operands of the insn. This improves 18504 register allocation because the register allocator often looks at 18505 operands 1 and 2 of insns to see if it can do register tying. 18506 18507 There is no way to specify constraints in `match_operator'. The 18508 operand of the insn which corresponds to the `match_operator' 18509 never has any constraints because it is never reloaded as a whole. 18510 However, if parts of its OPERANDS are matched by `match_operand' 18511 patterns, those parts may have constraints of their own. 18512 18513`(match_op_dup:M N[OPERANDS...])' 18514 Like `match_dup', except that it applies to operators instead of 18515 operands. When constructing an insn, operand number N will be 18516 substituted at this point. But in matching, `match_op_dup' behaves 18517 differently. It assumes that operand number N has already been 18518 determined by a `match_operator' appearing earlier in the 18519 recognition template, and it matches only an identical-looking 18520 expression. 18521 18522`(match_parallel N PREDICATE [SUBPAT...])' 18523 This pattern is a placeholder for an insn that consists of a 18524 `parallel' expression with a variable number of elements. This 18525 expression should only appear at the top level of an insn pattern. 18526 18527 When constructing an insn, operand number N will be substituted at 18528 this point. When matching an insn, it matches if the body of the 18529 insn is a `parallel' expression with at least as many elements as 18530 the vector of SUBPAT expressions in the `match_parallel', if each 18531 SUBPAT matches the corresponding element of the `parallel', _and_ 18532 the function PREDICATE returns nonzero on the `parallel' that is 18533 the body of the insn. It is the responsibility of the predicate 18534 to validate elements of the `parallel' beyond those listed in the 18535 `match_parallel'. 18536 18537 A typical use of `match_parallel' is to match load and store 18538 multiple expressions, which can contain a variable number of 18539 elements in a `parallel'. For example, 18540 18541 (define_insn "" 18542 [(match_parallel 0 "load_multiple_operation" 18543 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 18544 (match_operand:SI 2 "memory_operand" "m")) 18545 (use (reg:SI 179)) 18546 (clobber (reg:SI 179))])] 18547 "" 18548 "loadm 0,0,%1,%2") 18549 18550 This example comes from `a29k.md'. The function 18551 `load_multiple_operation' is defined in `a29k.c' and checks that 18552 subsequent elements in the `parallel' are the same as the `set' in 18553 the pattern, except that they are referencing subsequent registers 18554 and memory locations. 18555 18556 An insn that matches this pattern might look like: 18557 18558 (parallel 18559 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 18560 (use (reg:SI 179)) 18561 (clobber (reg:SI 179)) 18562 (set (reg:SI 21) 18563 (mem:SI (plus:SI (reg:SI 100) 18564 (const_int 4)))) 18565 (set (reg:SI 22) 18566 (mem:SI (plus:SI (reg:SI 100) 18567 (const_int 8))))]) 18568 18569`(match_par_dup N [SUBPAT...])' 18570 Like `match_op_dup', but for `match_parallel' instead of 18571 `match_operator'. 18572 18573 18574 18575File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 18576 1857716.5 Output Templates and Operand Substitution 18578============================================== 18579 18580The "output template" is a string which specifies how to output the 18581assembler code for an instruction pattern. Most of the template is a 18582fixed string which is output literally. The character `%' is used to 18583specify where to substitute an operand; it can also be used to identify 18584places where different variants of the assembler require different 18585syntax. 18586 18587 In the simplest case, a `%' followed by a digit N says to output 18588operand N at that point in the string. 18589 18590 `%' followed by a letter and a digit says to output an operand in an 18591alternate fashion. Four letters have standard, built-in meanings 18592described below. The machine description macro `PRINT_OPERAND' can 18593define additional letters with nonstandard meanings. 18594 18595 `%cDIGIT' can be used to substitute an operand that is a constant 18596value without the syntax that normally indicates an immediate operand. 18597 18598 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 18599negated before printing. 18600 18601 `%aDIGIT' can be used to substitute an operand as if it were a memory 18602reference, with the actual operand treated as the address. This may be 18603useful when outputting a "load address" instruction, because often the 18604assembler syntax for such an instruction requires you to write the 18605operand as if it were a memory reference. 18606 18607 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction. 18608 18609 `%=' outputs a number which is unique to each instruction in the 18610entire compilation. This is useful for making local labels to be 18611referred to more than once in a single template that generates multiple 18612assembler instructions. 18613 18614 `%' followed by a punctuation character specifies a substitution that 18615does not use an operand. Only one case is standard: `%%' outputs a `%' 18616into the assembler code. Other nonstandard cases can be defined in the 18617`PRINT_OPERAND' macro. You must also define which punctuation 18618characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 18619 18620 The template may generate multiple assembler instructions. Write the 18621text for the instructions, with `\;' between them. 18622 18623 When the RTL contains two operands which are required by constraint to 18624match each other, the output template must refer only to the 18625lower-numbered operand. Matching operands are not always identical, 18626and the rest of the compiler arranges to put the proper RTL expression 18627for printing into the lower-numbered operand. 18628 18629 One use of nonstandard letters or punctuation following `%' is to 18630distinguish between different assembler languages for the same machine; 18631for example, Motorola syntax versus MIT syntax for the 68000. Motorola 18632syntax requires periods in most opcode names, while MIT syntax does 18633not. For example, the opcode `movel' in MIT syntax is `move.l' in 18634Motorola syntax. The same file of patterns is used for both kinds of 18635output syntax, but the character sequence `%.' is used in each place 18636where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 18637Motorola syntax defines the sequence to output a period; the macro for 18638MIT syntax defines it to do nothing. 18639 18640 As a special case, a template consisting of the single character `#' 18641instructs the compiler to first split the insn, and then output the 18642resulting instructions separately. This helps eliminate redundancy in 18643the output templates. If you have a `define_insn' that needs to emit 18644multiple assembler instructions, and there is a matching `define_split' 18645already defined, then you can simply use `#' as the output template 18646instead of writing an output template that emits the multiple assembler 18647instructions. 18648 18649 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of 18650the form `{option0|option1|option2}' in the templates. These describe 18651multiple variants of assembler language syntax. *Note Instruction 18652Output::. 18653 18654 18655File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 18656 1865716.6 C Statements for Assembler Output 18658====================================== 18659 18660Often a single fixed template string cannot produce correct and 18661efficient assembler code for all the cases that are recognized by a 18662single instruction pattern. For example, the opcodes may depend on the 18663kinds of operands; or some unfortunate combinations of operands may 18664require extra machine instructions. 18665 18666 If the output control string starts with a `@', then it is actually a 18667series of templates, each on a separate line. (Blank lines and leading 18668spaces and tabs are ignored.) The templates correspond to the 18669pattern's constraint alternatives (*note Multi-Alternative::). For 18670example, if a target machine has a two-address add instruction `addr' 18671to add into a register and another `addm' to add a register to memory, 18672you might write this pattern: 18673 18674 (define_insn "addsi3" 18675 [(set (match_operand:SI 0 "general_operand" "=r,m") 18676 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 18677 (match_operand:SI 2 "general_operand" "g,r")))] 18678 "" 18679 "@ 18680 addr %2,%0 18681 addm %2,%0") 18682 18683 If the output control string starts with a `*', then it is not an 18684output template but rather a piece of C program that should compute a 18685template. It should execute a `return' statement to return the 18686template-string you want. Most such templates use C string literals, 18687which require doublequote characters to delimit them. To include these 18688doublequote characters in the string, prefix each one with `\'. 18689 18690 If the output control string is written as a brace block instead of a 18691double-quoted string, it is automatically assumed to be C code. In that 18692case, it is not necessary to put in a leading asterisk, or to escape the 18693doublequotes surrounding C string literals. 18694 18695 The operands may be found in the array `operands', whose C data type 18696is `rtx []'. 18697 18698 It is very common to select different ways of generating assembler code 18699based on whether an immediate operand is within a certain range. Be 18700careful when doing this, because the result of `INTVAL' is an integer 18701on the host machine. If the host machine has more bits in an `int' 18702than the target machine has in the mode in which the constant will be 18703used, then some of the bits you get from `INTVAL' will be superfluous. 18704For proper results, you must carefully disregard the values of those 18705bits. 18706 18707 It is possible to output an assembler instruction and then go on to 18708output or compute more of them, using the subroutine `output_asm_insn'. 18709This receives two arguments: a template-string and a vector of 18710operands. The vector may be `operands', or it may be another array of 18711`rtx' that you declare locally and initialize yourself. 18712 18713 When an insn pattern has multiple alternatives in its constraints, 18714often the appearance of the assembler code is determined mostly by 18715which alternative was matched. When this is so, the C code can test 18716the variable `which_alternative', which is the ordinal number of the 18717alternative that was actually satisfied (0 for the first, 1 for the 18718second alternative, etc.). 18719 18720 For example, suppose there are two opcodes for storing zero, `clrreg' 18721for registers and `clrmem' for memory locations. Here is how a pattern 18722could use `which_alternative' to choose between them: 18723 18724 (define_insn "" 18725 [(set (match_operand:SI 0 "general_operand" "=r,m") 18726 (const_int 0))] 18727 "" 18728 { 18729 return (which_alternative == 0 18730 ? "clrreg %0" : "clrmem %0"); 18731 }) 18732 18733 The example above, where the assembler code to generate was _solely_ 18734determined by the alternative, could also have been specified as 18735follows, having the output control string start with a `@': 18736 18737 (define_insn "" 18738 [(set (match_operand:SI 0 "general_operand" "=r,m") 18739 (const_int 0))] 18740 "" 18741 "@ 18742 clrreg %0 18743 clrmem %0") 18744 18745 If you just need a little bit of C code in one (or a few) alternatives, 18746you can use `*' inside of a `@' multi-alternative template: 18747 18748 (define_insn "" 18749 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 18750 (const_int 0))] 18751 "" 18752 "@ 18753 clrreg %0 18754 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 18755 clrmem %0") 18756 18757 18758File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 18759 1876016.7 Predicates 18761=============== 18762 18763A predicate determines whether a `match_operand' or `match_operator' 18764expression matches, and therefore whether the surrounding instruction 18765pattern will be used for that combination of operands. GCC has a 18766number of machine-independent predicates, and you can define 18767machine-specific predicates as needed. By convention, predicates used 18768with `match_operand' have names that end in `_operand', and those used 18769with `match_operator' have names that end in `_operator'. 18770 18771 All predicates are Boolean functions (in the mathematical sense) of 18772two arguments: the RTL expression that is being considered at that 18773position in the instruction pattern, and the machine mode that the 18774`match_operand' or `match_operator' specifies. In this section, the 18775first argument is called OP and the second argument MODE. Predicates 18776can be called from C as ordinary two-argument functions; this can be 18777useful in output templates or other machine-specific code. 18778 18779 Operand predicates can allow operands that are not actually acceptable 18780to the hardware, as long as the constraints give reload the ability to 18781fix them up (*note Constraints::). However, GCC will usually generate 18782better code if the predicates specify the requirements of the machine 18783instructions as closely as possible. Reload cannot fix up operands 18784that must be constants ("immediate operands"); you must use a predicate 18785that allows only constants, or else enforce the requirement in the 18786extra condition. 18787 18788 Most predicates handle their MODE argument in a uniform manner. If 18789MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE 18790is anything else, then OP must have the same mode, unless OP is a 18791`CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always 18792have `VOIDmode', so it would be counterproductive to check that their 18793mode matches. Instead, predicates that accept `CONST_INT' and/or 18794integer `CONST_DOUBLE' check that the value stored in the constant will 18795fit in the requested mode. 18796 18797 Predicates with this behavior are called "normal". `genrecog' can 18798optimize the instruction recognizer based on knowledge of how normal 18799predicates treat modes. It can also diagnose certain kinds of common 18800errors in the use of normal predicates; for instance, it is almost 18801always an error to use a normal predicate without specifying a mode. 18802 18803 Predicates that do something different with their MODE argument are 18804called "special". The generic predicates `address_operand' and 18805`pmode_register_operand' are special predicates. `genrecog' does not 18806do any optimizations or diagnosis when special predicates are used. 18807 18808* Menu: 18809 18810* Machine-Independent Predicates:: Predicates available to all back ends. 18811* Defining Predicates:: How to write machine-specific predicate 18812 functions. 18813 18814 18815File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 18816 1881716.7.1 Machine-Independent Predicates 18818------------------------------------- 18819 18820These are the generic predicates available to all back ends. They are 18821defined in `recog.c'. The first category of predicates allow only 18822constant, or "immediate", operands. 18823 18824 -- Function: immediate_operand 18825 This predicate allows any sort of constant that fits in MODE. It 18826 is an appropriate choice for instructions that take operands that 18827 must be constant. 18828 18829 -- Function: const_int_operand 18830 This predicate allows any `CONST_INT' expression that fits in 18831 MODE. It is an appropriate choice for an immediate operand that 18832 does not allow a symbol or label. 18833 18834 -- Function: const_double_operand 18835 This predicate accepts any `CONST_DOUBLE' expression that has 18836 exactly MODE. If MODE is `VOIDmode', it will also accept 18837 `CONST_INT'. It is intended for immediate floating point 18838 constants. 18839 18840The second category of predicates allow only some kind of machine 18841register. 18842 18843 -- Function: register_operand 18844 This predicate allows any `REG' or `SUBREG' expression that is 18845 valid for MODE. It is often suitable for arithmetic instruction 18846 operands on a RISC machine. 18847 18848 -- Function: pmode_register_operand 18849 This is a slight variant on `register_operand' which works around 18850 a limitation in the machine-description reader. 18851 18852 (match_operand N "pmode_register_operand" CONSTRAINT) 18853 18854 means exactly what 18855 18856 (match_operand:P N "register_operand" CONSTRAINT) 18857 18858 would mean, if the machine-description reader accepted `:P' mode 18859 suffixes. Unfortunately, it cannot, because `Pmode' is an alias 18860 for some other mode, and might vary with machine-specific options. 18861 *Note Misc::. 18862 18863 -- Function: scratch_operand 18864 This predicate allows hard registers and `SCRATCH' expressions, 18865 but not pseudo-registers. It is used internally by 18866 `match_scratch'; it should not be used directly. 18867 18868The third category of predicates allow only some kind of memory 18869reference. 18870 18871 -- Function: memory_operand 18872 This predicate allows any valid reference to a quantity of mode 18873 MODE in memory, as determined by the weak form of 18874 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 18875 18876 -- Function: address_operand 18877 This predicate is a little unusual; it allows any operand that is a 18878 valid expression for the _address_ of a quantity of mode MODE, 18879 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'. 18880 To first order, if `(mem:MODE (EXP))' is acceptable to 18881 `memory_operand', then EXP is acceptable to `address_operand'. 18882 Note that EXP does not necessarily have the mode MODE. 18883 18884 -- Function: indirect_operand 18885 This is a stricter form of `memory_operand' which allows only 18886 memory references with a `general_operand' as the address 18887 expression. New uses of this predicate are discouraged, because 18888 `general_operand' is very permissive, so it's hard to tell what an 18889 `indirect_operand' does or does not allow. If a target has 18890 different requirements for memory operands for different 18891 instructions, it is better to define target-specific predicates 18892 which enforce the hardware's requirements explicitly. 18893 18894 -- Function: push_operand 18895 This predicate allows a memory reference suitable for pushing a 18896 value onto the stack. This will be a `MEM' which refers to 18897 `stack_pointer_rtx', with a side-effect in its address expression 18898 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE' 18899 macro (*note Frame Layout::). 18900 18901 -- Function: pop_operand 18902 This predicate allows a memory reference suitable for popping a 18903 value off the stack. Again, this will be a `MEM' referring to 18904 `stack_pointer_rtx', with a side-effect in its address expression. 18905 However, this time `STACK_POP_CODE' is expected. 18906 18907The fourth category of predicates allow some combination of the above 18908operands. 18909 18910 -- Function: nonmemory_operand 18911 This predicate allows any immediate or register operand valid for 18912 MODE. 18913 18914 -- Function: nonimmediate_operand 18915 This predicate allows any register or memory operand valid for 18916 MODE. 18917 18918 -- Function: general_operand 18919 This predicate allows any immediate, register, or memory operand 18920 valid for MODE. 18921 18922Finally, there are two generic operator predicates. 18923 18924 -- Function: comparison_operator 18925 This predicate matches any expression which performs an arithmetic 18926 comparison in MODE; that is, `COMPARISON_P' is true for the 18927 expression code. 18928 18929 -- Function: ordered_comparison_operator 18930 This predicate matches any expression which performs an arithmetic 18931 comparison in MODE and whose expression code is valid for integer 18932 modes; that is, the expression code will be one of `eq', `ne', 18933 `lt', `ltu', `le', `leu', `gt', `gtu', `ge', `geu'. 18934 18935 18936File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 18937 1893816.7.2 Defining Machine-Specific Predicates 18939------------------------------------------- 18940 18941Many machines have requirements for their operands that cannot be 18942expressed precisely using the generic predicates. You can define 18943additional predicates using `define_predicate' and 18944`define_special_predicate' expressions. These expressions have three 18945operands: 18946 18947 * The name of the predicate, as it will be referred to in 18948 `match_operand' or `match_operator' expressions. 18949 18950 * An RTL expression which evaluates to true if the predicate allows 18951 the operand OP, false if it does not. This expression can only use 18952 the following RTL codes: 18953 18954 `MATCH_OPERAND' 18955 When written inside a predicate expression, a `MATCH_OPERAND' 18956 expression evaluates to true if the predicate it names would 18957 allow OP. The operand number and constraint are ignored. 18958 Due to limitations in `genrecog', you can only refer to 18959 generic predicates and predicates that have already been 18960 defined. 18961 18962 `MATCH_CODE' 18963 This expression evaluates to true if OP or a specified 18964 subexpression of OP has one of a given list of RTX codes. 18965 18966 The first operand of this expression is a string constant 18967 containing a comma-separated list of RTX code names (in lower 18968 case). These are the codes for which the `MATCH_CODE' will 18969 be true. 18970 18971 The second operand is a string constant which indicates what 18972 subexpression of OP to examine. If it is absent or the empty 18973 string, OP itself is examined. Otherwise, the string constant 18974 must be a sequence of digits and/or lowercase letters. Each 18975 character indicates a subexpression to extract from the 18976 current expression; for the first character this is OP, for 18977 the second and subsequent characters it is the result of the 18978 previous character. A digit N extracts `XEXP (E, N)'; a 18979 letter L extracts `XVECEXP (E, 0, N)' where N is the 18980 alphabetic ordinal of L (0 for `a', 1 for 'b', and so on). 18981 The `MATCH_CODE' then examines the RTX code of the 18982 subexpression extracted by the complete string. It is not 18983 possible to extract components of an `rtvec' that is not at 18984 position 0 within its RTX object. 18985 18986 `MATCH_TEST' 18987 This expression has one operand, a string constant containing 18988 a C expression. The predicate's arguments, OP and MODE, are 18989 available with those names in the C expression. The 18990 `MATCH_TEST' evaluates to true if the C expression evaluates 18991 to a nonzero value. `MATCH_TEST' expressions must not have 18992 side effects. 18993 18994 `AND' 18995 `IOR' 18996 `NOT' 18997 `IF_THEN_ELSE' 18998 The basic `MATCH_' expressions can be combined using these 18999 logical operators, which have the semantics of the C operators 19000 `&&', `||', `!', and `? :' respectively. As in Common Lisp, 19001 you may give an `AND' or `IOR' expression an arbitrary number 19002 of arguments; this has exactly the same effect as writing a 19003 chain of two-argument `AND' or `IOR' expressions. 19004 19005 * An optional block of C code, which should execute `return true' if 19006 the predicate is found to match and `return false' if it does not. 19007 It must not have any side effects. The predicate arguments, OP 19008 and MODE, are available with those names. 19009 19010 If a code block is present in a predicate definition, then the RTL 19011 expression must evaluate to true _and_ the code block must execute 19012 `return true' for the predicate to allow the operand. The RTL 19013 expression is evaluated first; do not re-check anything in the 19014 code block that was checked in the RTL expression. 19015 19016 The program `genrecog' scans `define_predicate' and 19017`define_special_predicate' expressions to determine which RTX codes are 19018possibly allowed. You should always make this explicit in the RTL 19019predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'. 19020 19021 Here is an example of a simple predicate definition, from the IA64 19022machine description: 19023 19024 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section. 19025 (define_predicate "small_addr_symbolic_operand" 19026 (and (match_code "symbol_ref") 19027 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 19028 19029And here is another, showing the use of the C block. 19030 19031 ;; True if OP is a register operand that is (or could be) a GR reg. 19032 (define_predicate "gr_register_operand" 19033 (match_operand 0 "register_operand") 19034 { 19035 unsigned int regno; 19036 if (GET_CODE (op) == SUBREG) 19037 op = SUBREG_REG (op); 19038 19039 regno = REGNO (op); 19040 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 19041 }) 19042 19043 Predicates written with `define_predicate' automatically include a 19044test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is 19045a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for 19046integer `CONST_DOUBLE', nor do they test that the value of either kind 19047of constant fits in the requested mode. This is because 19048target-specific predicates that take constants usually have to do more 19049stringent value checks anyway. If you need the exact same treatment of 19050`CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use 19051a `MATCH_OPERAND' subexpression to call `const_int_operand', 19052`const_double_operand', or `immediate_operand'. 19053 19054 Predicates written with `define_special_predicate' do not get any 19055automatic mode checks, and are treated as having special mode handling 19056by `genrecog'. 19057 19058 The program `genpreds' is responsible for generating code to test 19059predicates. It also writes a header file containing function 19060declarations for all machine-specific predicates. It is not necessary 19061to declare these predicates in `CPU-protos.h'. 19062 19063 19064File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 19065 1906616.8 Operand Constraints 19067======================== 19068 19069Each `match_operand' in an instruction pattern can specify constraints 19070for the operands allowed. The constraints allow you to fine-tune 19071matching within the set of operands allowed by the predicate. 19072 19073 Constraints can say whether an operand may be in a register, and which 19074kinds of register; whether the operand can be a memory reference, and 19075which kinds of address; whether the operand may be an immediate 19076constant, and which possible values it may have. Constraints can also 19077require two operands to match. Side-effects aren't allowed in operands 19078of inline `asm', unless `<' or `>' constraints are used, because there 19079is no guarantee that the side-effects will happen exactly once in an 19080instruction that can update the addressing register. 19081 19082* Menu: 19083 19084* Simple Constraints:: Basic use of constraints. 19085* Multi-Alternative:: When an insn has two alternative constraint-patterns. 19086* Class Preferences:: Constraints guide which hard register to put things in. 19087* Modifiers:: More precise control over effects of constraints. 19088* Machine Constraints:: Existing constraints for some particular machines. 19089* Disable Insn Alternatives:: Disable insn alternatives using the `enabled' attribute. 19090* Define Constraints:: How to define machine-specific constraints. 19091* C Constraint Interface:: How to test constraints from C code. 19092 19093 19094File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 19095 1909616.8.1 Simple Constraints 19097------------------------- 19098 19099The simplest kind of constraint is a string full of letters, each of 19100which describes one kind of operand that is permitted. Here are the 19101letters that are allowed: 19102 19103whitespace 19104 Whitespace characters are ignored and can be inserted at any 19105 position except the first. This enables each alternative for 19106 different operands to be visually aligned in the machine 19107 description even if they have different number of constraints and 19108 modifiers. 19109 19110`m' 19111 A memory operand is allowed, with any kind of address that the 19112 machine supports in general. Note that the letter used for the 19113 general memory constraint can be re-defined by a back end using 19114 the `TARGET_MEM_CONSTRAINT' macro. 19115 19116`o' 19117 A memory operand is allowed, but only if the address is 19118 "offsettable". This means that adding a small integer (actually, 19119 the width in bytes of the operand, as determined by its machine 19120 mode) may be added to the address and the result is also a valid 19121 memory address. 19122 19123 For example, an address which is constant is offsettable; so is an 19124 address that is the sum of a register and a constant (as long as a 19125 slightly larger constant is also within the range of 19126 address-offsets supported by the machine); but an autoincrement or 19127 autodecrement address is not offsettable. More complicated 19128 indirect/indexed addresses may or may not be offsettable depending 19129 on the other addressing modes that the machine supports. 19130 19131 Note that in an output operand which can be matched by another 19132 operand, the constraint letter `o' is valid only when accompanied 19133 by both `<' (if the target machine has predecrement addressing) 19134 and `>' (if the target machine has preincrement addressing). 19135 19136`V' 19137 A memory operand that is not offsettable. In other words, 19138 anything that would fit the `m' constraint but not the `o' 19139 constraint. 19140 19141`<' 19142 A memory operand with autodecrement addressing (either 19143 predecrement or postdecrement) is allowed. In inline `asm' this 19144 constraint is only allowed if the operand is used exactly once in 19145 an instruction that can handle the side-effects. Not using an 19146 operand with `<' in constraint string in the inline `asm' pattern 19147 at all or using it in multiple instructions isn't valid, because 19148 the side-effects wouldn't be performed or would be performed more 19149 than once. Furthermore, on some targets the operand with `<' in 19150 constraint string must be accompanied by special instruction 19151 suffixes like `%U0' instruction suffix on PowerPC or `%P0' on 19152 IA-64. 19153 19154`>' 19155 A memory operand with autoincrement addressing (either 19156 preincrement or postincrement) is allowed. In inline `asm' the 19157 same restrictions as for `<' apply. 19158 19159`r' 19160 A register operand is allowed provided that it is in a general 19161 register. 19162 19163`i' 19164 An immediate integer operand (one with constant value) is allowed. 19165 This includes symbolic constants whose values will be known only at 19166 assembly time or later. 19167 19168`n' 19169 An immediate integer operand with a known numeric value is allowed. 19170 Many systems cannot support assembly-time constants for operands 19171 less than a word wide. Constraints for these operands should use 19172 `n' rather than `i'. 19173 19174`I', `J', `K', ... `P' 19175 Other letters in the range `I' through `P' may be defined in a 19176 machine-dependent fashion to permit immediate integer operands with 19177 explicit integer values in specified ranges. For example, on the 19178 68000, `I' is defined to stand for the range of values 1 to 8. 19179 This is the range permitted as a shift count in the shift 19180 instructions. 19181 19182`E' 19183 An immediate floating operand (expression code `const_double') is 19184 allowed, but only if the target floating point format is the same 19185 as that of the host machine (on which the compiler is running). 19186 19187`F' 19188 An immediate floating operand (expression code `const_double' or 19189 `const_vector') is allowed. 19190 19191`G', `H' 19192 `G' and `H' may be defined in a machine-dependent fashion to 19193 permit immediate floating operands in particular ranges of values. 19194 19195`s' 19196 An immediate integer operand whose value is not an explicit 19197 integer is allowed. 19198 19199 This might appear strange; if an insn allows a constant operand 19200 with a value not known at compile time, it certainly must allow 19201 any known value. So why use `s' instead of `i'? Sometimes it 19202 allows better code to be generated. 19203 19204 For example, on the 68000 in a fullword instruction it is possible 19205 to use an immediate operand; but if the immediate value is between 19206 -128 and 127, better code results from loading the value into a 19207 register and using the register. This is because the load into 19208 the register can be done with a `moveq' instruction. We arrange 19209 for this to happen by defining the letter `K' to mean "any integer 19210 outside the range -128 to 127", and then specifying `Ks' in the 19211 operand constraints. 19212 19213`g' 19214 Any register, memory or immediate integer operand is allowed, 19215 except for registers that are not general registers. 19216 19217`X' 19218 Any operand whatsoever is allowed, even if it does not satisfy 19219 `general_operand'. This is normally used in the constraint of a 19220 `match_scratch' when certain alternatives will not actually 19221 require a scratch register. 19222 19223`0', `1', `2', ... `9' 19224 An operand that matches the specified operand number is allowed. 19225 If a digit is used together with letters within the same 19226 alternative, the digit should come last. 19227 19228 This number is allowed to be more than a single digit. If multiple 19229 digits are encountered consecutively, they are interpreted as a 19230 single decimal integer. There is scant chance for ambiguity, 19231 since to-date it has never been desirable that `10' be interpreted 19232 as matching either operand 1 _or_ operand 0. Should this be 19233 desired, one can use multiple alternatives instead. 19234 19235 This is called a "matching constraint" and what it really means is 19236 that the assembler has only a single operand that fills two roles 19237 considered separate in the RTL insn. For example, an add insn has 19238 two input operands and one output operand in the RTL, but on most 19239 CISC machines an add instruction really has only two operands, one 19240 of them an input-output operand: 19241 19242 addl #35,r12 19243 19244 Matching constraints are used in these circumstances. More 19245 precisely, the two operands that match must include one input-only 19246 operand and one output-only operand. Moreover, the digit must be a 19247 smaller number than the number of the operand that uses it in the 19248 constraint. 19249 19250 For operands to match in a particular case usually means that they 19251 are identical-looking RTL expressions. But in a few special cases 19252 specific kinds of dissimilarity are allowed. For example, `*x' as 19253 an input operand will match `*x++' as an output operand. For 19254 proper results in such cases, the output template should always 19255 use the output-operand's number when printing the operand. 19256 19257`p' 19258 An operand that is a valid memory address is allowed. This is for 19259 "load address" and "push address" instructions. 19260 19261 `p' in the constraint must be accompanied by `address_operand' as 19262 the predicate in the `match_operand'. This predicate interprets 19263 the mode specified in the `match_operand' as the mode of the memory 19264 reference for which the address would be valid. 19265 19266OTHER-LETTERS 19267 Other letters can be defined in machine-dependent fashion to stand 19268 for particular classes of registers or other arbitrary operand 19269 types. `d', `a' and `f' are defined on the 68000/68020 to stand 19270 for data, address and floating point registers. 19271 19272 In order to have valid assembler code, each operand must satisfy its 19273constraint. But a failure to do so does not prevent the pattern from 19274applying to an insn. Instead, it directs the compiler to modify the 19275code so that the constraint will be satisfied. Usually this is done by 19276copying an operand into a register. 19277 19278 Contrast, therefore, the two instruction patterns that follow: 19279 19280 (define_insn "" 19281 [(set (match_operand:SI 0 "general_operand" "=r") 19282 (plus:SI (match_dup 0) 19283 (match_operand:SI 1 "general_operand" "r")))] 19284 "" 19285 "...") 19286 19287which has two operands, one of which must appear in two places, and 19288 19289 (define_insn "" 19290 [(set (match_operand:SI 0 "general_operand" "=r") 19291 (plus:SI (match_operand:SI 1 "general_operand" "0") 19292 (match_operand:SI 2 "general_operand" "r")))] 19293 "" 19294 "...") 19295 19296which has three operands, two of which are required by a constraint to 19297be identical. If we are considering an insn of the form 19298 19299 (insn N PREV NEXT 19300 (set (reg:SI 3) 19301 (plus:SI (reg:SI 6) (reg:SI 109))) 19302 ...) 19303 19304the first pattern would not apply at all, because this insn does not 19305contain two identical subexpressions in the right place. The pattern 19306would say, "That does not look like an add instruction; try other 19307patterns". The second pattern would say, "Yes, that's an add 19308instruction, but there is something wrong with it". It would direct 19309the reload pass of the compiler to generate additional insns to make 19310the constraint true. The results might look like this: 19311 19312 (insn N2 PREV N 19313 (set (reg:SI 3) (reg:SI 6)) 19314 ...) 19315 19316 (insn N N2 NEXT 19317 (set (reg:SI 3) 19318 (plus:SI (reg:SI 3) (reg:SI 109))) 19319 ...) 19320 19321 It is up to you to make sure that each operand, in each pattern, has 19322constraints that can handle any RTL expression that could be present for 19323that operand. (When multiple alternatives are in use, each pattern 19324must, for each possible combination of operand expressions, have at 19325least one alternative which can handle that combination of operands.) 19326The constraints don't need to _allow_ any possible operand--when this is 19327the case, they do not constrain--but they must at least point the way to 19328reloading any possible operand so that it will fit. 19329 19330 * If the constraint accepts whatever operands the predicate permits, 19331 there is no problem: reloading is never necessary for this operand. 19332 19333 For example, an operand whose constraints permit everything except 19334 registers is safe provided its predicate rejects registers. 19335 19336 An operand whose predicate accepts only constant values is safe 19337 provided its constraints include the letter `i'. If any possible 19338 constant value is accepted, then nothing less than `i' will do; if 19339 the predicate is more selective, then the constraints may also be 19340 more selective. 19341 19342 * Any operand expression can be reloaded by copying it into a 19343 register. So if an operand's constraints allow some kind of 19344 register, it is certain to be safe. It need not permit all 19345 classes of registers; the compiler knows how to copy a register 19346 into another register of the proper class in order to make an 19347 instruction valid. 19348 19349 * A nonoffsettable memory reference can be reloaded by copying the 19350 address into a register. So if the constraint uses the letter 19351 `o', all memory references are taken care of. 19352 19353 * A constant operand can be reloaded by allocating space in memory to 19354 hold it as preinitialized data. Then the memory reference can be 19355 used in place of the constant. So if the constraint uses the 19356 letters `o' or `m', constant operands are not a problem. 19357 19358 * If the constraint permits a constant and a pseudo register used in 19359 an insn was not allocated to a hard register and is equivalent to 19360 a constant, the register will be replaced with the constant. If 19361 the predicate does not permit a constant and the insn is 19362 re-recognized for some reason, the compiler will crash. Thus the 19363 predicate must always recognize any objects allowed by the 19364 constraint. 19365 19366 If the operand's predicate can recognize registers, but the constraint 19367does not permit them, it can make the compiler crash. When this 19368operand happens to be a register, the reload pass will be stymied, 19369because it does not know how to copy a register temporarily into memory. 19370 19371 If the predicate accepts a unary operator, the constraint applies to 19372the operand. For example, the MIPS processor at ISA level 3 supports an 19373instruction which adds two registers in `SImode' to produce a `DImode' 19374result, but only if the registers are correctly sign extended. This 19375predicate for the input operands accepts a `sign_extend' of an `SImode' 19376register. Write the constraint to indicate the type of register that 19377is required for the operand of the `sign_extend'. 19378 19379 19380File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 19381 1938216.8.2 Multiple Alternative Constraints 19383--------------------------------------- 19384 19385Sometimes a single instruction has multiple alternative sets of possible 19386operands. For example, on the 68000, a logical-or instruction can 19387combine register or an immediate value into memory, or it can combine 19388any kind of operand into a register; but it cannot combine one memory 19389location into another. 19390 19391 These constraints are represented as multiple alternatives. An 19392alternative can be described by a series of letters for each operand. 19393The overall constraint for an operand is made from the letters for this 19394operand from the first alternative, a comma, the letters for this 19395operand from the second alternative, a comma, and so on until the last 19396alternative. Here is how it is done for fullword logical-or on the 1939768000: 19398 19399 (define_insn "iorsi3" 19400 [(set (match_operand:SI 0 "general_operand" "=m,d") 19401 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 19402 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 19403 ...) 19404 19405 The first alternative has `m' (memory) for operand 0, `0' for operand 194061 (meaning it must match operand 0), and `dKs' for operand 2. The 19407second alternative has `d' (data register) for operand 0, `0' for 19408operand 1, and `dmKs' for operand 2. The `=' and `%' in the 19409constraints apply to all the alternatives; their meaning is explained 19410in the next section (*note Class Preferences::). 19411 19412 If all the operands fit any one alternative, the instruction is valid. 19413Otherwise, for each alternative, the compiler counts how many 19414instructions must be added to copy the operands so that that 19415alternative applies. The alternative requiring the least copying is 19416chosen. If two alternatives need the same amount of copying, the one 19417that comes first is chosen. These choices can be altered with the `?' 19418and `!' characters: 19419 19420`?' 19421 Disparage slightly the alternative that the `?' appears in, as a 19422 choice when no alternative applies exactly. The compiler regards 19423 this alternative as one unit more costly for each `?' that appears 19424 in it. 19425 19426`!' 19427 Disparage severely the alternative that the `!' appears in. This 19428 alternative can still be used if it fits without reloading, but if 19429 reloading is needed, some other alternative will be used. 19430 19431 When an insn pattern has multiple alternatives in its constraints, 19432often the appearance of the assembler code is determined mostly by which 19433alternative was matched. When this is so, the C code for writing the 19434assembler code can use the variable `which_alternative', which is the 19435ordinal number of the alternative that was actually satisfied (0 for 19436the first, 1 for the second alternative, etc.). *Note Output 19437Statement::. 19438 19439 19440File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 19441 1944216.8.3 Register Class Preferences 19443--------------------------------- 19444 19445The operand constraints have another function: they enable the compiler 19446to decide which kind of hardware register a pseudo register is best 19447allocated to. The compiler examines the constraints that apply to the 19448insns that use the pseudo register, looking for the machine-dependent 19449letters such as `d' and `a' that specify classes of registers. The 19450pseudo register is put in whichever class gets the most "votes". The 19451constraint letters `g' and `r' also vote: they vote in favor of a 19452general register. The machine description says which registers are 19453considered general. 19454 19455 Of course, on some machines all registers are equivalent, and no 19456register classes are defined. Then none of this complexity is relevant. 19457 19458 19459File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 19460 1946116.8.4 Constraint Modifier Characters 19462------------------------------------- 19463 19464Here are constraint modifier characters. 19465 19466`=' 19467 Means that this operand is write-only for this instruction: the 19468 previous value is discarded and replaced by output data. 19469 19470`+' 19471 Means that this operand is both read and written by the 19472 instruction. 19473 19474 When the compiler fixes up the operands to satisfy the constraints, 19475 it needs to know which operands are inputs to the instruction and 19476 which are outputs from it. `=' identifies an output; `+' 19477 identifies an operand that is both input and output; all other 19478 operands are assumed to be input only. 19479 19480 If you specify `=' or `+' in a constraint, you put it in the first 19481 character of the constraint string. 19482 19483`&' 19484 Means (in a particular alternative) that this operand is an 19485 "earlyclobber" operand, which is modified before the instruction is 19486 finished using the input operands. Therefore, this operand may 19487 not lie in a register that is used as an input operand or as part 19488 of any memory address. 19489 19490 `&' applies only to the alternative in which it is written. In 19491 constraints with multiple alternatives, sometimes one alternative 19492 requires `&' while others do not. See, for example, the `movdf' 19493 insn of the 68000. 19494 19495 An input operand can be tied to an earlyclobber operand if its only 19496 use as an input occurs before the early result is written. Adding 19497 alternatives of this form often allows GCC to produce better code 19498 when only some of the inputs can be affected by the earlyclobber. 19499 See, for example, the `mulsi3' insn of the ARM. 19500 19501 `&' does not obviate the need to write `='. 19502 19503`%' 19504 Declares the instruction to be commutative for this operand and the 19505 following operand. This means that the compiler may interchange 19506 the two operands if that is the cheapest way to make all operands 19507 fit the constraints. This is often used in patterns for addition 19508 instructions that really have only two operands: the result must 19509 go in one of the arguments. Here for example, is how the 68000 19510 halfword-add instruction is defined: 19511 19512 (define_insn "addhi3" 19513 [(set (match_operand:HI 0 "general_operand" "=m,r") 19514 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 19515 (match_operand:HI 2 "general_operand" "di,g")))] 19516 ...) 19517 GCC can only handle one commutative pair in an asm; if you use 19518 more, the compiler may fail. Note that you need not use the 19519 modifier if the two alternatives are strictly identical; this 19520 would only waste time in the reload pass. The modifier is not 19521 operational after register allocation, so the result of 19522 `define_peephole2' and `define_split's performed after reload 19523 cannot rely on `%' to make the intended insn match. 19524 19525`#' 19526 Says that all following characters, up to the next comma, are to be 19527 ignored as a constraint. They are significant only for choosing 19528 register preferences. 19529 19530`*' 19531 Says that the following character should be ignored when choosing 19532 register preferences. `*' has no effect on the meaning of the 19533 constraint as a constraint, and no effect on reloading. For LRA 19534 `*' additionally disparages slightly the alternative if the 19535 following character matches the operand. 19536 19537 Here is an example: the 68000 has an instruction to sign-extend a 19538 halfword in a data register, and can also sign-extend a value by 19539 copying it into an address register. While either kind of 19540 register is acceptable, the constraints on an address-register 19541 destination are less strict, so it is best if register allocation 19542 makes an address register its goal. Therefore, `*' is used so 19543 that the `d' constraint letter (for data register) is ignored when 19544 computing register preferences. 19545 19546 (define_insn "extendhisi2" 19547 [(set (match_operand:SI 0 "general_operand" "=*d,a") 19548 (sign_extend:SI 19549 (match_operand:HI 1 "general_operand" "0,g")))] 19550 ...) 19551 19552 19553File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 19554 1955516.8.5 Constraints for Particular Machines 19556------------------------------------------ 19557 19558Whenever possible, you should use the general-purpose constraint letters 19559in `asm' arguments, since they will convey meaning more readily to 19560people reading your code. Failing that, use the constraint letters 19561that usually have very similar meanings across architectures. The most 19562commonly used constraints are `m' and `r' (for memory and 19563general-purpose registers respectively; *note Simple Constraints::), and 19564`I', usually the letter indicating the most common immediate-constant 19565format. 19566 19567 Each architecture defines additional constraints. These constraints 19568are used by the compiler itself for instruction generation, as well as 19569for `asm' statements; therefore, some of the constraints are not 19570particularly useful for `asm'. Here is a summary of some of the 19571machine-dependent constraints available on some particular machines; it 19572includes both constraints that are useful for `asm' and constraints 19573that aren't. The compiler source file mentioned in the table heading 19574for each architecture is the definitive reference for the meanings of 19575that architecture's constraints. 19576 19577_AArch64 family--`config/aarch64/constraints.md'_ 19578 19579 `k' 19580 The stack pointer register (`SP') 19581 19582 `w' 19583 Floating point or SIMD vector register 19584 19585 `I' 19586 Integer constant that is valid as an immediate operand in an 19587 `ADD' instruction 19588 19589 `J' 19590 Integer constant that is valid as an immediate operand in a 19591 `SUB' instruction (once negated) 19592 19593 `K' 19594 Integer constant that can be used with a 32-bit logical 19595 instruction 19596 19597 `L' 19598 Integer constant that can be used with a 64-bit logical 19599 instruction 19600 19601 `M' 19602 Integer constant that is valid as an immediate operand in a 19603 32-bit `MOV' pseudo instruction. The `MOV' may be assembled 19604 to one of several different machine instructions depending on 19605 the value 19606 19607 `N' 19608 Integer constant that is valid as an immediate operand in a 19609 64-bit `MOV' pseudo instruction 19610 19611 `S' 19612 An absolute symbolic address or a label reference 19613 19614 `Y' 19615 Floating point constant zero 19616 19617 `Z' 19618 Integer constant zero 19619 19620 `Usa' 19621 An absolute symbolic address 19622 19623 `Ush' 19624 The high part (bits 12 and upwards) of the pc-relative 19625 address of a symbol within 4GB of the instruction 19626 19627 `Q' 19628 A memory address which uses a single base register with no 19629 offset 19630 19631 `Ump' 19632 A memory address suitable for a load/store pair instruction 19633 in SI, DI, SF and DF modes 19634 19635 19636_ARM family--`config/arm/constraints.md'_ 19637 19638 `w' 19639 VFP floating-point register 19640 19641 `G' 19642 The floating-point constant 0.0 19643 19644 `I' 19645 Integer that is valid as an immediate operand in a data 19646 processing instruction. That is, an integer in the range 0 19647 to 255 rotated by a multiple of 2 19648 19649 `J' 19650 Integer in the range -4095 to 4095 19651 19652 `K' 19653 Integer that satisfies constraint `I' when inverted (ones 19654 complement) 19655 19656 `L' 19657 Integer that satisfies constraint `I' when negated (twos 19658 complement) 19659 19660 `M' 19661 Integer in the range 0 to 32 19662 19663 `Q' 19664 A memory reference where the exact address is in a single 19665 register (``m'' is preferable for `asm' statements) 19666 19667 `R' 19668 An item in the constant pool 19669 19670 `S' 19671 A symbol in the text segment of the current file 19672 19673 `Uv' 19674 A memory reference suitable for VFP load/store insns 19675 (reg+constant offset) 19676 19677 `Uy' 19678 A memory reference suitable for iWMMXt load/store 19679 instructions. 19680 19681 `Uq' 19682 A memory reference suitable for the ARMv4 ldrsb instruction. 19683 19684_AVR family--`config/avr/constraints.md'_ 19685 19686 `l' 19687 Registers from r0 to r15 19688 19689 `a' 19690 Registers from r16 to r23 19691 19692 `d' 19693 Registers from r16 to r31 19694 19695 `w' 19696 Registers from r24 to r31. These registers can be used in 19697 `adiw' command 19698 19699 `e' 19700 Pointer register (r26-r31) 19701 19702 `b' 19703 Base pointer register (r28-r31) 19704 19705 `q' 19706 Stack pointer register (SPH:SPL) 19707 19708 `t' 19709 Temporary register r0 19710 19711 `x' 19712 Register pair X (r27:r26) 19713 19714 `y' 19715 Register pair Y (r29:r28) 19716 19717 `z' 19718 Register pair Z (r31:r30) 19719 19720 `I' 19721 Constant greater than -1, less than 64 19722 19723 `J' 19724 Constant greater than -64, less than 1 19725 19726 `K' 19727 Constant integer 2 19728 19729 `L' 19730 Constant integer 0 19731 19732 `M' 19733 Constant that fits in 8 bits 19734 19735 `N' 19736 Constant integer -1 19737 19738 `O' 19739 Constant integer 8, 16, or 24 19740 19741 `P' 19742 Constant integer 1 19743 19744 `G' 19745 A floating point constant 0.0 19746 19747 `Q' 19748 A memory address based on Y or Z pointer with displacement. 19749 19750_Epiphany--`config/epiphany/constraints.md'_ 19751 19752 `U16' 19753 An unsigned 16-bit constant. 19754 19755 `K' 19756 An unsigned 5-bit constant. 19757 19758 `L' 19759 A signed 11-bit constant. 19760 19761 `Cm1' 19762 A signed 11-bit constant added to -1. Can only match when 19763 the `-m1reg-REG' option is active. 19764 19765 `Cl1' 19766 Left-shift of -1, i.e., a bit mask with a block of leading 19767 ones, the rest being a block of trailing zeroes. Can only 19768 match when the `-m1reg-REG' option is active. 19769 19770 `Cr1' 19771 Right-shift of -1, i.e., a bit mask with a trailing block of 19772 ones, the rest being zeroes. Or to put it another way, one 19773 less than a power of two. Can only match when the 19774 `-m1reg-REG' option is active. 19775 19776 `Cal' 19777 Constant for arithmetic/logical operations. This is like 19778 `i', except that for position independent code, no symbols / 19779 expressions needing relocations are allowed. 19780 19781 `Csy' 19782 Symbolic constant for call/jump instruction. 19783 19784 `Rcs' 19785 The register class usable in short insns. This is a register 19786 class constraint, and can thus drive register allocation. 19787 This constraint won't match unless `-mprefer-short-insn-regs' 19788 is in effect. 19789 19790 `Rsc' 19791 The the register class of registers that can be used to hold a 19792 sibcall call address. I.e., a caller-saved register. 19793 19794 `Rct' 19795 Core control register class. 19796 19797 `Rgs' 19798 The register group usable in short insns. This constraint 19799 does not use a register class, so that it only passively 19800 matches suitable registers, and doesn't drive register 19801 allocation. 19802 19803 `Car' 19804 Constant suitable for the addsi3_r pattern. This is a valid 19805 offset For byte, halfword, or word addressing. 19806 19807 `Rra' 19808 Matches the return address if it can be replaced with the 19809 link register. 19810 19811 `Rcc' 19812 Matches the integer condition code register. 19813 19814 `Sra' 19815 Matches the return address if it is in a stack slot. 19816 19817 `Cfm' 19818 Matches control register values to switch fp mode, which are 19819 encapsulated in `UNSPEC_FP_MODE'. 19820 19821_CR16 Architecture--`config/cr16/cr16.h'_ 19822 19823 `b' 19824 Registers from r0 to r14 (registers without stack pointer) 19825 19826 `t' 19827 Register from r0 to r11 (all 16-bit registers) 19828 19829 `p' 19830 Register from r12 to r15 (all 32-bit registers) 19831 19832 `I' 19833 Signed constant that fits in 4 bits 19834 19835 `J' 19836 Signed constant that fits in 5 bits 19837 19838 `K' 19839 Signed constant that fits in 6 bits 19840 19841 `L' 19842 Unsigned constant that fits in 4 bits 19843 19844 `M' 19845 Signed constant that fits in 32 bits 19846 19847 `N' 19848 Check for 64 bits wide constants for add/sub instructions 19849 19850 `G' 19851 Floating point constant that is legal for store immediate 19852 19853_Hewlett-Packard PA-RISC--`config/pa/pa.h'_ 19854 19855 `a' 19856 General register 1 19857 19858 `f' 19859 Floating point register 19860 19861 `q' 19862 Shift amount register 19863 19864 `x' 19865 Floating point register (deprecated) 19866 19867 `y' 19868 Upper floating point register (32-bit), floating point 19869 register (64-bit) 19870 19871 `Z' 19872 Any register 19873 19874 `I' 19875 Signed 11-bit integer constant 19876 19877 `J' 19878 Signed 14-bit integer constant 19879 19880 `K' 19881 Integer constant that can be deposited with a `zdepi' 19882 instruction 19883 19884 `L' 19885 Signed 5-bit integer constant 19886 19887 `M' 19888 Integer constant 0 19889 19890 `N' 19891 Integer constant that can be loaded with a `ldil' instruction 19892 19893 `O' 19894 Integer constant whose value plus one is a power of 2 19895 19896 `P' 19897 Integer constant that can be used for `and' operations in 19898 `depi' and `extru' instructions 19899 19900 `S' 19901 Integer constant 31 19902 19903 `U' 19904 Integer constant 63 19905 19906 `G' 19907 Floating-point constant 0.0 19908 19909 `A' 19910 A `lo_sum' data-linkage-table memory operand 19911 19912 `Q' 19913 A memory operand that can be used as the destination operand 19914 of an integer store instruction 19915 19916 `R' 19917 A scaled or unscaled indexed memory operand 19918 19919 `T' 19920 A memory operand for floating-point loads and stores 19921 19922 `W' 19923 A register indirect memory operand 19924 19925_picoChip family--`picochip.h'_ 19926 19927 `k' 19928 Stack register. 19929 19930 `f' 19931 Pointer register. A register which can be used to access 19932 memory without supplying an offset. Any other register can 19933 be used to access memory, but will need a constant offset. 19934 In the case of the offset being zero, it is more efficient to 19935 use a pointer register, since this reduces code size. 19936 19937 `t' 19938 A twin register. A register which may be paired with an 19939 adjacent register to create a 32-bit register. 19940 19941 `a' 19942 Any absolute memory address (e.g., symbolic constant, symbolic 19943 constant + offset). 19944 19945 `I' 19946 4-bit signed integer. 19947 19948 `J' 19949 4-bit unsigned integer. 19950 19951 `K' 19952 8-bit signed integer. 19953 19954 `M' 19955 Any constant whose absolute value is no greater than 4-bits. 19956 19957 `N' 19958 10-bit signed integer 19959 19960 `O' 19961 16-bit signed integer. 19962 19963 19964_PowerPC and IBM RS6000--`config/rs6000/constraints.md'_ 19965 19966 `b' 19967 Address base register 19968 19969 `d' 19970 Floating point register (containing 64-bit value) 19971 19972 `f' 19973 Floating point register (containing 32-bit value) 19974 19975 `v' 19976 Altivec vector register 19977 19978 `wa' 19979 Any VSX register if the -mvsx option was used or NO_REGS. 19980 19981 When using any of the register constraints (`wa', `wd', `wf', 19982 `wg', `wh', `wi', `wj', `wk', `wl', `wm', `ws', `wt', `wu', 19983 `wv', `ww', or `wy') that take VSX registers, you must use 19984 `%x<n>' in the template so that the correct register is used. 19985 Otherwise the register number output in the assembly file 19986 will be incorrect if an Altivec register is an operand of a 19987 VSX instruction that expects VSX register numbering. 19988 19989 asm ("xvadddp %x0,%x1,%x2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 19990 19991 is correct, but: 19992 19993 asm ("xvadddp %0,%1,%2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 19994 19995 is not correct. 19996 19997 `wd' 19998 VSX vector register to hold vector double data or NO_REGS. 19999 20000 `wf' 20001 VSX vector register to hold vector float data or NO_REGS. 20002 20003 `wg' 20004 If `-mmfpgpr' was used, a floating point register or NO_REGS. 20005 20006 `wh' 20007 Floating point register if direct moves are available, or 20008 NO_REGS. 20009 20010 `wi' 20011 FP or VSX register to hold 64-bit integers for VSX insns or 20012 NO_REGS. 20013 20014 `wj' 20015 FP or VSX register to hold 64-bit integers for direct moves 20016 or NO_REGS. 20017 20018 `wk' 20019 FP or VSX register to hold 64-bit doubles for direct moves or 20020 NO_REGS. 20021 20022 `wl' 20023 Floating point register if the LFIWAX instruction is enabled 20024 or NO_REGS. 20025 20026 `wm' 20027 VSX register if direct move instructions are enabled, or 20028 NO_REGS. 20029 20030 `wn' 20031 No register (NO_REGS). 20032 20033 `wr' 20034 General purpose register if 64-bit instructions are enabled 20035 or NO_REGS. 20036 20037 `ws' 20038 VSX vector register to hold scalar double values or NO_REGS. 20039 20040 `wt' 20041 VSX vector register to hold 128 bit integer or NO_REGS. 20042 20043 `wu' 20044 Altivec register to use for float/32-bit int loads/stores or 20045 NO_REGS. 20046 20047 `wv' 20048 Altivec register to use for double loads/stores or NO_REGS. 20049 20050 `ww' 20051 FP or VSX register to perform float operations under `-mvsx' 20052 or NO_REGS. 20053 20054 `wx' 20055 Floating point register if the STFIWX instruction is enabled 20056 or NO_REGS. 20057 20058 `wy' 20059 FP or VSX register to perform ISA 2.07 float ops or NO_REGS. 20060 20061 `wz' 20062 Floating point register if the LFIWZX instruction is enabled 20063 or NO_REGS. 20064 20065 `wQ' 20066 A memory address that will work with the `lq' and `stq' 20067 instructions. 20068 20069 `h' 20070 `MQ', `CTR', or `LINK' register 20071 20072 `q' 20073 `MQ' register 20074 20075 `c' 20076 `CTR' register 20077 20078 `l' 20079 `LINK' register 20080 20081 `x' 20082 `CR' register (condition register) number 0 20083 20084 `y' 20085 `CR' register (condition register) 20086 20087 `z' 20088 `XER[CA]' carry bit (part of the XER register) 20089 20090 `I' 20091 Signed 16-bit constant 20092 20093 `J' 20094 Unsigned 16-bit constant shifted left 16 bits (use `L' 20095 instead for `SImode' constants) 20096 20097 `K' 20098 Unsigned 16-bit constant 20099 20100 `L' 20101 Signed 16-bit constant shifted left 16 bits 20102 20103 `M' 20104 Constant larger than 31 20105 20106 `N' 20107 Exact power of 2 20108 20109 `O' 20110 Zero 20111 20112 `P' 20113 Constant whose negation is a signed 16-bit constant 20114 20115 `G' 20116 Floating point constant that can be loaded into a register 20117 with one instruction per word 20118 20119 `H' 20120 Integer/Floating point constant that can be loaded into a 20121 register using three instructions 20122 20123 `m' 20124 Memory operand. Normally, `m' does not allow addresses that 20125 update the base register. If `<' or `>' constraint is also 20126 used, they are allowed and therefore on PowerPC targets in 20127 that case it is only safe to use `m<>' in an `asm' statement 20128 if that `asm' statement accesses the operand exactly once. 20129 The `asm' statement must also use `%U<OPNO>' as a placeholder 20130 for the "update" flag in the corresponding load or store 20131 instruction. For example: 20132 20133 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 20134 20135 is correct but: 20136 20137 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 20138 20139 is not. 20140 20141 `es' 20142 A "stable" memory operand; that is, one which does not 20143 include any automodification of the base register. This used 20144 to be useful when `m' allowed automodification of the base 20145 register, but as those are now only allowed when `<' or `>' 20146 is used, `es' is basically the same as `m' without `<' and 20147 `>'. 20148 20149 `Q' 20150 Memory operand that is an offset from a register (it is 20151 usually better to use `m' or `es' in `asm' statements) 20152 20153 `Z' 20154 Memory operand that is an indexed or indirect from a register 20155 (it is usually better to use `m' or `es' in `asm' statements) 20156 20157 `R' 20158 AIX TOC entry 20159 20160 `a' 20161 Address operand that is an indexed or indirect from a 20162 register (`p' is preferable for `asm' statements) 20163 20164 `S' 20165 Constant suitable as a 64-bit mask operand 20166 20167 `T' 20168 Constant suitable as a 32-bit mask operand 20169 20170 `U' 20171 System V Release 4 small data area reference 20172 20173 `t' 20174 AND masks that can be performed by two rldic{l, r} 20175 instructions 20176 20177 `W' 20178 Vector constant that does not require memory 20179 20180 `j' 20181 Vector constant that is all zeros. 20182 20183 20184_Intel 386--`config/i386/constraints.md'_ 20185 20186 `R' 20187 Legacy register--the eight integer registers available on all 20188 i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp'). 20189 20190 `q' 20191 Any register accessible as `Rl'. In 32-bit mode, `a', `b', 20192 `c', and `d'; in 64-bit mode, any integer register. 20193 20194 `Q' 20195 Any register accessible as `Rh': `a', `b', `c', and `d'. 20196 20197 `l' 20198 Any register that can be used as the index in a base+index 20199 memory access: that is, any general register except the stack 20200 pointer. 20201 20202 `a' 20203 The `a' register. 20204 20205 `b' 20206 The `b' register. 20207 20208 `c' 20209 The `c' register. 20210 20211 `d' 20212 The `d' register. 20213 20214 `S' 20215 The `si' register. 20216 20217 `D' 20218 The `di' register. 20219 20220 `A' 20221 The `a' and `d' registers. This class is used for 20222 instructions that return double word results in the `ax:dx' 20223 register pair. Single word values will be allocated either 20224 in `ax' or `dx'. For example on i386 the following 20225 implements `rdtsc': 20226 20227 unsigned long long rdtsc (void) 20228 { 20229 unsigned long long tick; 20230 __asm__ __volatile__("rdtsc":"=A"(tick)); 20231 return tick; 20232 } 20233 20234 This is not correct on x86_64 as it would allocate tick in 20235 either `ax' or `dx'. You have to use the following variant 20236 instead: 20237 20238 unsigned long long rdtsc (void) 20239 { 20240 unsigned int tickl, tickh; 20241 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 20242 return ((unsigned long long)tickh << 32)|tickl; 20243 } 20244 20245 `f' 20246 Any 80387 floating-point (stack) register. 20247 20248 `t' 20249 Top of 80387 floating-point stack (`%st(0)'). 20250 20251 `u' 20252 Second from top of 80387 floating-point stack (`%st(1)'). 20253 20254 `y' 20255 Any MMX register. 20256 20257 `x' 20258 Any SSE register. 20259 20260 `Yz' 20261 First SSE register (`%xmm0'). 20262 20263 `Y2' 20264 Any SSE register, when SSE2 is enabled. 20265 20266 `Yi' 20267 Any SSE register, when SSE2 and inter-unit moves are enabled. 20268 20269 `Ym' 20270 Any MMX register, when inter-unit moves are enabled. 20271 20272 `I' 20273 Integer constant in the range 0 ... 31, for 32-bit shifts. 20274 20275 `J' 20276 Integer constant in the range 0 ... 63, for 64-bit shifts. 20277 20278 `K' 20279 Signed 8-bit integer constant. 20280 20281 `L' 20282 `0xFF' or `0xFFFF', for andsi as a zero-extending move. 20283 20284 `M' 20285 0, 1, 2, or 3 (shifts for the `lea' instruction). 20286 20287 `N' 20288 Unsigned 8-bit integer constant (for `in' and `out' 20289 instructions). 20290 20291 `O' 20292 Integer constant in the range 0 ... 127, for 128-bit shifts. 20293 20294 `G' 20295 Standard 80387 floating point constant. 20296 20297 `C' 20298 Standard SSE floating point constant. 20299 20300 `e' 20301 32-bit signed integer constant, or a symbolic reference known 20302 to fit that range (for immediate operands in sign-extending 20303 x86-64 instructions). 20304 20305 `Z' 20306 32-bit unsigned integer constant, or a symbolic reference 20307 known to fit that range (for immediate operands in 20308 zero-extending x86-64 instructions). 20309 20310 20311_Intel IA-64--`config/ia64/ia64.h'_ 20312 20313 `a' 20314 General register `r0' to `r3' for `addl' instruction 20315 20316 `b' 20317 Branch register 20318 20319 `c' 20320 Predicate register (`c' as in "conditional") 20321 20322 `d' 20323 Application register residing in M-unit 20324 20325 `e' 20326 Application register residing in I-unit 20327 20328 `f' 20329 Floating-point register 20330 20331 `m' 20332 Memory operand. If used together with `<' or `>', the 20333 operand can have postincrement and postdecrement which 20334 require printing with `%Pn' on IA-64. 20335 20336 `G' 20337 Floating-point constant 0.0 or 1.0 20338 20339 `I' 20340 14-bit signed integer constant 20341 20342 `J' 20343 22-bit signed integer constant 20344 20345 `K' 20346 8-bit signed integer constant for logical instructions 20347 20348 `L' 20349 8-bit adjusted signed integer constant for compare pseudo-ops 20350 20351 `M' 20352 6-bit unsigned integer constant for shift counts 20353 20354 `N' 20355 9-bit signed integer constant for load and store 20356 postincrements 20357 20358 `O' 20359 The constant zero 20360 20361 `P' 20362 0 or -1 for `dep' instruction 20363 20364 `Q' 20365 Non-volatile memory for floating-point loads and stores 20366 20367 `R' 20368 Integer constant in the range 1 to 4 for `shladd' instruction 20369 20370 `S' 20371 Memory operand except postincrement and postdecrement. This 20372 is now roughly the same as `m' when not used together with `<' 20373 or `>'. 20374 20375_FRV--`config/frv/frv.h'_ 20376 20377 `a' 20378 Register in the class `ACC_REGS' (`acc0' to `acc7'). 20379 20380 `b' 20381 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). 20382 20383 `c' 20384 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' 20385 to `icc3'). 20386 20387 `d' 20388 Register in the class `GPR_REGS' (`gr0' to `gr63'). 20389 20390 `e' 20391 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd 20392 registers are excluded not in the class but through the use 20393 of a machine mode larger than 4 bytes. 20394 20395 `f' 20396 Register in the class `FPR_REGS' (`fr0' to `fr63'). 20397 20398 `h' 20399 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd 20400 registers are excluded not in the class but through the use 20401 of a machine mode larger than 4 bytes. 20402 20403 `l' 20404 Register in the class `LR_REG' (the `lr' register). 20405 20406 `q' 20407 Register in the class `QUAD_REGS' (`gr2' to `gr63'). 20408 Register numbers not divisible by 4 are excluded not in the 20409 class but through the use of a machine mode larger than 8 20410 bytes. 20411 20412 `t' 20413 Register in the class `ICC_REGS' (`icc0' to `icc3'). 20414 20415 `u' 20416 Register in the class `FCC_REGS' (`fcc0' to `fcc3'). 20417 20418 `v' 20419 Register in the class `ICR_REGS' (`cc4' to `cc7'). 20420 20421 `w' 20422 Register in the class `FCR_REGS' (`cc0' to `cc3'). 20423 20424 `x' 20425 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). 20426 Register numbers not divisible by 4 are excluded not in the 20427 class but through the use of a machine mode larger than 8 20428 bytes. 20429 20430 `z' 20431 Register in the class `SPR_REGS' (`lcr' and `lr'). 20432 20433 `A' 20434 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). 20435 20436 `B' 20437 Register in the class `ACCG_REGS' (`accg0' to `accg7'). 20438 20439 `C' 20440 Register in the class `CR_REGS' (`cc0' to `cc7'). 20441 20442 `G' 20443 Floating point constant zero 20444 20445 `I' 20446 6-bit signed integer constant 20447 20448 `J' 20449 10-bit signed integer constant 20450 20451 `L' 20452 16-bit signed integer constant 20453 20454 `M' 20455 16-bit unsigned integer constant 20456 20457 `N' 20458 12-bit signed integer constant that is negative--i.e. in the 20459 range of -2048 to -1 20460 20461 `O' 20462 Constant zero 20463 20464 `P' 20465 12-bit signed integer constant that is greater than 20466 zero--i.e. in the range of 1 to 2047. 20467 20468 20469_Blackfin family--`config/bfin/constraints.md'_ 20470 20471 `a' 20472 P register 20473 20474 `d' 20475 D register 20476 20477 `z' 20478 A call clobbered P register. 20479 20480 `qN' 20481 A single register. If N is in the range 0 to 7, the 20482 corresponding D register. If it is `A', then the register P0. 20483 20484 `D' 20485 Even-numbered D register 20486 20487 `W' 20488 Odd-numbered D register 20489 20490 `e' 20491 Accumulator register. 20492 20493 `A' 20494 Even-numbered accumulator register. 20495 20496 `B' 20497 Odd-numbered accumulator register. 20498 20499 `b' 20500 I register 20501 20502 `v' 20503 B register 20504 20505 `f' 20506 M register 20507 20508 `c' 20509 Registers used for circular buffering, i.e. I, B, or L 20510 registers. 20511 20512 `C' 20513 The CC register. 20514 20515 `t' 20516 LT0 or LT1. 20517 20518 `k' 20519 LC0 or LC1. 20520 20521 `u' 20522 LB0 or LB1. 20523 20524 `x' 20525 Any D, P, B, M, I or L register. 20526 20527 `y' 20528 Additional registers typically used only in prologues and 20529 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 20530 USP. 20531 20532 `w' 20533 Any register except accumulators or CC. 20534 20535 `Ksh' 20536 Signed 16 bit integer (in the range -32768 to 32767) 20537 20538 `Kuh' 20539 Unsigned 16 bit integer (in the range 0 to 65535) 20540 20541 `Ks7' 20542 Signed 7 bit integer (in the range -64 to 63) 20543 20544 `Ku7' 20545 Unsigned 7 bit integer (in the range 0 to 127) 20546 20547 `Ku5' 20548 Unsigned 5 bit integer (in the range 0 to 31) 20549 20550 `Ks4' 20551 Signed 4 bit integer (in the range -8 to 7) 20552 20553 `Ks3' 20554 Signed 3 bit integer (in the range -3 to 4) 20555 20556 `Ku3' 20557 Unsigned 3 bit integer (in the range 0 to 7) 20558 20559 `PN' 20560 Constant N, where N is a single-digit constant in the range 0 20561 to 4. 20562 20563 `PA' 20564 An integer equal to one of the MACFLAG_XXX constants that is 20565 suitable for use with either accumulator. 20566 20567 `PB' 20568 An integer equal to one of the MACFLAG_XXX constants that is 20569 suitable for use only with accumulator A1. 20570 20571 `M1' 20572 Constant 255. 20573 20574 `M2' 20575 Constant 65535. 20576 20577 `J' 20578 An integer constant with exactly a single bit set. 20579 20580 `L' 20581 An integer constant with all bits set except exactly one. 20582 20583 `H' 20584 20585 `Q' 20586 Any SYMBOL_REF. 20587 20588_M32C--`config/m32c/m32c.c'_ 20589 20590 `Rsp' 20591 `Rfb' 20592 `Rsb' 20593 `$sp', `$fb', `$sb'. 20594 20595 `Rcr' 20596 Any control register, when they're 16 bits wide (nothing if 20597 control registers are 24 bits wide) 20598 20599 `Rcl' 20600 Any control register, when they're 24 bits wide. 20601 20602 `R0w' 20603 `R1w' 20604 `R2w' 20605 `R3w' 20606 $r0, $r1, $r2, $r3. 20607 20608 `R02' 20609 $r0 or $r2, or $r2r0 for 32 bit values. 20610 20611 `R13' 20612 $r1 or $r3, or $r3r1 for 32 bit values. 20613 20614 `Rdi' 20615 A register that can hold a 64 bit value. 20616 20617 `Rhl' 20618 $r0 or $r1 (registers with addressable high/low bytes) 20619 20620 `R23' 20621 $r2 or $r3 20622 20623 `Raa' 20624 Address registers 20625 20626 `Raw' 20627 Address registers when they're 16 bits wide. 20628 20629 `Ral' 20630 Address registers when they're 24 bits wide. 20631 20632 `Rqi' 20633 Registers that can hold QI values. 20634 20635 `Rad' 20636 Registers that can be used with displacements ($a0, $a1, $sb). 20637 20638 `Rsi' 20639 Registers that can hold 32 bit values. 20640 20641 `Rhi' 20642 Registers that can hold 16 bit values. 20643 20644 `Rhc' 20645 Registers chat can hold 16 bit values, including all control 20646 registers. 20647 20648 `Rra' 20649 $r0 through R1, plus $a0 and $a1. 20650 20651 `Rfl' 20652 The flags register. 20653 20654 `Rmm' 20655 The memory-based pseudo-registers $mem0 through $mem15. 20656 20657 `Rpi' 20658 Registers that can hold pointers (16 bit registers for r8c, 20659 m16c; 24 bit registers for m32cm, m32c). 20660 20661 `Rpa' 20662 Matches multiple registers in a PARALLEL to form a larger 20663 register. Used to match function return values. 20664 20665 `Is3' 20666 -8 ... 7 20667 20668 `IS1' 20669 -128 ... 127 20670 20671 `IS2' 20672 -32768 ... 32767 20673 20674 `IU2' 20675 0 ... 65535 20676 20677 `In4' 20678 -8 ... -1 or 1 ... 8 20679 20680 `In5' 20681 -16 ... -1 or 1 ... 16 20682 20683 `In6' 20684 -32 ... -1 or 1 ... 32 20685 20686 `IM2' 20687 -65536 ... -1 20688 20689 `Ilb' 20690 An 8 bit value with exactly one bit set. 20691 20692 `Ilw' 20693 A 16 bit value with exactly one bit set. 20694 20695 `Sd' 20696 The common src/dest memory addressing modes. 20697 20698 `Sa' 20699 Memory addressed using $a0 or $a1. 20700 20701 `Si' 20702 Memory addressed with immediate addresses. 20703 20704 `Ss' 20705 Memory addressed using the stack pointer ($sp). 20706 20707 `Sf' 20708 Memory addressed using the frame base register ($fb). 20709 20710 `Ss' 20711 Memory addressed using the small base register ($sb). 20712 20713 `S1' 20714 $r1h 20715 20716_MeP--`config/mep/constraints.md'_ 20717 20718 `a' 20719 The $sp register. 20720 20721 `b' 20722 The $tp register. 20723 20724 `c' 20725 Any control register. 20726 20727 `d' 20728 Either the $hi or the $lo register. 20729 20730 `em' 20731 Coprocessor registers that can be directly loaded ($c0-$c15). 20732 20733 `ex' 20734 Coprocessor registers that can be moved to each other. 20735 20736 `er' 20737 Coprocessor registers that can be moved to core registers. 20738 20739 `h' 20740 The $hi register. 20741 20742 `j' 20743 The $rpc register. 20744 20745 `l' 20746 The $lo register. 20747 20748 `t' 20749 Registers which can be used in $tp-relative addressing. 20750 20751 `v' 20752 The $gp register. 20753 20754 `x' 20755 The coprocessor registers. 20756 20757 `y' 20758 The coprocessor control registers. 20759 20760 `z' 20761 The $0 register. 20762 20763 `A' 20764 User-defined register set A. 20765 20766 `B' 20767 User-defined register set B. 20768 20769 `C' 20770 User-defined register set C. 20771 20772 `D' 20773 User-defined register set D. 20774 20775 `I' 20776 Offsets for $gp-rel addressing. 20777 20778 `J' 20779 Constants that can be used directly with boolean insns. 20780 20781 `K' 20782 Constants that can be moved directly to registers. 20783 20784 `L' 20785 Small constants that can be added to registers. 20786 20787 `M' 20788 Long shift counts. 20789 20790 `N' 20791 Small constants that can be compared to registers. 20792 20793 `O' 20794 Constants that can be loaded into the top half of registers. 20795 20796 `S' 20797 Signed 8-bit immediates. 20798 20799 `T' 20800 Symbols encoded for $tp-rel or $gp-rel addressing. 20801 20802 `U' 20803 Non-constant addresses for loading/saving coprocessor 20804 registers. 20805 20806 `W' 20807 The top half of a symbol's value. 20808 20809 `Y' 20810 A register indirect address without offset. 20811 20812 `Z' 20813 Symbolic references to the control bus. 20814 20815 20816_MicroBlaze--`config/microblaze/constraints.md'_ 20817 20818 `d' 20819 A general register (`r0' to `r31'). 20820 20821 `z' 20822 A status register (`rmsr', `$fcc1' to `$fcc7'). 20823 20824 20825_MIPS--`config/mips/constraints.md'_ 20826 20827 `d' 20828 An address register. This is equivalent to `r' unless 20829 generating MIPS16 code. 20830 20831 `f' 20832 A floating-point register (if available). 20833 20834 `h' 20835 Formerly the `hi' register. This constraint is no longer 20836 supported. 20837 20838 `l' 20839 The `lo' register. Use this register to store values that are 20840 no bigger than a word. 20841 20842 `x' 20843 The concatenated `hi' and `lo' registers. Use this register 20844 to store doubleword values. 20845 20846 `c' 20847 A register suitable for use in an indirect jump. This will 20848 always be `$25' for `-mabicalls'. 20849 20850 `v' 20851 Register `$3'. Do not use this constraint in new code; it is 20852 retained only for compatibility with glibc. 20853 20854 `y' 20855 Equivalent to `r'; retained for backwards compatibility. 20856 20857 `z' 20858 A floating-point condition code register. 20859 20860 `I' 20861 A signed 16-bit constant (for arithmetic instructions). 20862 20863 `J' 20864 Integer zero. 20865 20866 `K' 20867 An unsigned 16-bit constant (for logic instructions). 20868 20869 `L' 20870 A signed 32-bit constant in which the lower 16 bits are zero. 20871 Such constants can be loaded using `lui'. 20872 20873 `M' 20874 A constant that cannot be loaded using `lui', `addiu' or 20875 `ori'. 20876 20877 `N' 20878 A constant in the range -65535 to -1 (inclusive). 20879 20880 `O' 20881 A signed 15-bit constant. 20882 20883 `P' 20884 A constant in the range 1 to 65535 (inclusive). 20885 20886 `G' 20887 Floating-point zero. 20888 20889 `R' 20890 An address that can be used in a non-macro load or store. 20891 20892_Motorola 680x0--`config/m68k/constraints.md'_ 20893 20894 `a' 20895 Address register 20896 20897 `d' 20898 Data register 20899 20900 `f' 20901 68881 floating-point register, if available 20902 20903 `I' 20904 Integer in the range 1 to 8 20905 20906 `J' 20907 16-bit signed number 20908 20909 `K' 20910 Signed number whose magnitude is greater than 0x80 20911 20912 `L' 20913 Integer in the range -8 to -1 20914 20915 `M' 20916 Signed number whose magnitude is greater than 0x100 20917 20918 `N' 20919 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 20920 20921 `O' 20922 16 (for rotate using swap) 20923 20924 `P' 20925 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 20926 20927 `R' 20928 Numbers that mov3q can handle 20929 20930 `G' 20931 Floating point constant that is not a 68881 constant 20932 20933 `S' 20934 Operands that satisfy 'm' when -mpcrel is in effect 20935 20936 `T' 20937 Operands that satisfy 's' when -mpcrel is not in effect 20938 20939 `Q' 20940 Address register indirect addressing mode 20941 20942 `U' 20943 Register offset addressing 20944 20945 `W' 20946 const_call_operand 20947 20948 `Cs' 20949 symbol_ref or const 20950 20951 `Ci' 20952 const_int 20953 20954 `C0' 20955 const_int 0 20956 20957 `Cj' 20958 Range of signed numbers that don't fit in 16 bits 20959 20960 `Cmvq' 20961 Integers valid for mvq 20962 20963 `Capsw' 20964 Integers valid for a moveq followed by a swap 20965 20966 `Cmvz' 20967 Integers valid for mvz 20968 20969 `Cmvs' 20970 Integers valid for mvs 20971 20972 `Ap' 20973 push_operand 20974 20975 `Ac' 20976 Non-register operands allowed in clr 20977 20978 20979_Moxie--`config/moxie/constraints.md'_ 20980 20981 `A' 20982 An absolute address 20983 20984 `B' 20985 An offset address 20986 20987 `W' 20988 A register indirect memory operand 20989 20990 `I' 20991 A constant in the range of 0 to 255. 20992 20993 `N' 20994 A constant in the range of 0 to -255. 20995 20996 20997_PDP-11--`config/pdp11/constraints.md'_ 20998 20999 `a' 21000 Floating point registers AC0 through AC3. These can be 21001 loaded from/to memory with a single instruction. 21002 21003 `d' 21004 Odd numbered general registers (R1, R3, R5). These are used 21005 for 16-bit multiply operations. 21006 21007 `f' 21008 Any of the floating point registers (AC0 through AC5). 21009 21010 `G' 21011 Floating point constant 0. 21012 21013 `I' 21014 An integer constant that fits in 16 bits. 21015 21016 `J' 21017 An integer constant whose low order 16 bits are zero. 21018 21019 `K' 21020 An integer constant that does not meet the constraints for 21021 codes `I' or `J'. 21022 21023 `L' 21024 The integer constant 1. 21025 21026 `M' 21027 The integer constant -1. 21028 21029 `N' 21030 The integer constant 0. 21031 21032 `O' 21033 Integer constants -4 through -1 and 1 through 4; shifts by 21034 these amounts are handled as multiple single-bit shifts 21035 rather than a single variable-length shift. 21036 21037 `Q' 21038 A memory reference which requires an additional word (address 21039 or offset) after the opcode. 21040 21041 `R' 21042 A memory reference that is encoded within the opcode. 21043 21044 21045_RL78--`config/rl78/constraints.md'_ 21046 21047 `Int3' 21048 An integer constant in the range 1 ... 7. 21049 21050 `Int8' 21051 An integer constant in the range 0 ... 255. 21052 21053 `J' 21054 An integer constant in the range -255 ... 0 21055 21056 `K' 21057 The integer constant 1. 21058 21059 `L' 21060 The integer constant -1. 21061 21062 `M' 21063 The integer constant 0. 21064 21065 `N' 21066 The integer constant 2. 21067 21068 `O' 21069 The integer constant -2. 21070 21071 `P' 21072 An integer constant in the range 1 ... 15. 21073 21074 `Qbi' 21075 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 21076 21077 `Qsc' 21078 The synthetic compare types-gt, lt, ge, and le. 21079 21080 `Wab' 21081 A memory reference with an absolute address. 21082 21083 `Wbc' 21084 A memory reference using `BC' as a base register, with an 21085 optional offset. 21086 21087 `Wca' 21088 A memory reference using `AX', `BC', `DE', or `HL' for the 21089 address, for calls. 21090 21091 `Wcv' 21092 A memory reference using any 16-bit register pair for the 21093 address, for calls. 21094 21095 `Wd2' 21096 A memory reference using `DE' as a base register, with an 21097 optional offset. 21098 21099 `Wde' 21100 A memory reference using `DE' as a base register, without any 21101 offset. 21102 21103 `Wfr' 21104 Any memory reference to an address in the far address space. 21105 21106 `Wh1' 21107 A memory reference using `HL' as a base register, with an 21108 optional one-byte offset. 21109 21110 `Whb' 21111 A memory reference using `HL' as a base register, with `B' or 21112 `C' as the index register. 21113 21114 `Whl' 21115 A memory reference using `HL' as a base register, without any 21116 offset. 21117 21118 `Ws1' 21119 A memory reference using `SP' as a base register, with an 21120 optional one-byte offset. 21121 21122 `Y' 21123 Any memory reference to an address in the near address space. 21124 21125 `A' 21126 The `AX' register. 21127 21128 `B' 21129 The `BC' register. 21130 21131 `D' 21132 The `DE' register. 21133 21134 `R' 21135 `A' through `L' registers. 21136 21137 `S' 21138 The `SP' register. 21139 21140 `T' 21141 The `HL' register. 21142 21143 `Z08W' 21144 The 16-bit `R8' register. 21145 21146 `Z10W' 21147 The 16-bit `R10' register. 21148 21149 `Zint' 21150 The registers reserved for interrupts (`R24' to `R31'). 21151 21152 `a' 21153 The `A' register. 21154 21155 `b' 21156 The `B' register. 21157 21158 `c' 21159 The `C' register. 21160 21161 `d' 21162 The `D' register. 21163 21164 `e' 21165 The `E' register. 21166 21167 `h' 21168 The `H' register. 21169 21170 `l' 21171 The `L' register. 21172 21173 `v' 21174 The virtual registers. 21175 21176 `w' 21177 The `PSW' register. 21178 21179 `x' 21180 The `X' register. 21181 21182 21183_RX--`config/rx/constraints.md'_ 21184 21185 `Q' 21186 An address which does not involve register indirect 21187 addressing or pre/post increment/decrement addressing. 21188 21189 `Symbol' 21190 A symbol reference. 21191 21192 `Int08' 21193 A constant in the range -256 to 255, inclusive. 21194 21195 `Sint08' 21196 A constant in the range -128 to 127, inclusive. 21197 21198 `Sint16' 21199 A constant in the range -32768 to 32767, inclusive. 21200 21201 `Sint24' 21202 A constant in the range -8388608 to 8388607, inclusive. 21203 21204 `Uint04' 21205 A constant in the range 0 to 15, inclusive. 21206 21207 21208_SPARC--`config/sparc/sparc.h'_ 21209 21210 `f' 21211 Floating-point register on the SPARC-V8 architecture and 21212 lower floating-point register on the SPARC-V9 architecture. 21213 21214 `e' 21215 Floating-point register. It is equivalent to `f' on the 21216 SPARC-V8 architecture and contains both lower and upper 21217 floating-point registers on the SPARC-V9 architecture. 21218 21219 `c' 21220 Floating-point condition code register. 21221 21222 `d' 21223 Lower floating-point register. It is only valid on the 21224 SPARC-V9 architecture when the Visual Instruction Set is 21225 available. 21226 21227 `b' 21228 Floating-point register. It is only valid on the SPARC-V9 21229 architecture when the Visual Instruction Set is available. 21230 21231 `h' 21232 64-bit global or out register for the SPARC-V8+ architecture. 21233 21234 `C' 21235 The constant all-ones, for floating-point. 21236 21237 `A' 21238 Signed 5-bit constant 21239 21240 `D' 21241 A vector constant 21242 21243 `I' 21244 Signed 13-bit constant 21245 21246 `J' 21247 Zero 21248 21249 `K' 21250 32-bit constant with the low 12 bits clear (a constant that 21251 can be loaded with the `sethi' instruction) 21252 21253 `L' 21254 A constant in the range supported by `movcc' instructions 21255 (11-bit signed immediate) 21256 21257 `M' 21258 A constant in the range supported by `movrcc' instructions 21259 (10-bit signed immediate) 21260 21261 `N' 21262 Same as `K', except that it verifies that bits that are not 21263 in the lower 32-bit range are all zero. Must be used instead 21264 of `K' for modes wider than `SImode' 21265 21266 `O' 21267 The constant 4096 21268 21269 `G' 21270 Floating-point zero 21271 21272 `H' 21273 Signed 13-bit constant, sign-extended to 32 or 64 bits 21274 21275 `P' 21276 The constant -1 21277 21278 `Q' 21279 Floating-point constant whose integral representation can be 21280 moved into an integer register using a single sethi 21281 instruction 21282 21283 `R' 21284 Floating-point constant whose integral representation can be 21285 moved into an integer register using a single mov instruction 21286 21287 `S' 21288 Floating-point constant whose integral representation can be 21289 moved into an integer register using a high/lo_sum 21290 instruction sequence 21291 21292 `T' 21293 Memory address aligned to an 8-byte boundary 21294 21295 `U' 21296 Even register 21297 21298 `W' 21299 Memory address for `e' constraint registers 21300 21301 `w' 21302 Memory address with only a base register 21303 21304 `Y' 21305 Vector zero 21306 21307 21308_SPU--`config/spu/spu.h'_ 21309 21310 `a' 21311 An immediate which can be loaded with the il/ila/ilh/ilhu 21312 instructions. const_int is treated as a 64 bit value. 21313 21314 `c' 21315 An immediate for and/xor/or instructions. const_int is 21316 treated as a 64 bit value. 21317 21318 `d' 21319 An immediate for the `iohl' instruction. const_int is 21320 treated as a 64 bit value. 21321 21322 `f' 21323 An immediate which can be loaded with `fsmbi'. 21324 21325 `A' 21326 An immediate which can be loaded with the il/ila/ilh/ilhu 21327 instructions. const_int is treated as a 32 bit value. 21328 21329 `B' 21330 An immediate for most arithmetic instructions. const_int is 21331 treated as a 32 bit value. 21332 21333 `C' 21334 An immediate for and/xor/or instructions. const_int is 21335 treated as a 32 bit value. 21336 21337 `D' 21338 An immediate for the `iohl' instruction. const_int is 21339 treated as a 32 bit value. 21340 21341 `I' 21342 A constant in the range [-64, 63] for shift/rotate 21343 instructions. 21344 21345 `J' 21346 An unsigned 7-bit constant for conversion/nop/channel 21347 instructions. 21348 21349 `K' 21350 A signed 10-bit constant for most arithmetic instructions. 21351 21352 `M' 21353 A signed 16 bit immediate for `stop'. 21354 21355 `N' 21356 An unsigned 16-bit constant for `iohl' and `fsmbi'. 21357 21358 `O' 21359 An unsigned 7-bit constant whose 3 least significant bits are 21360 0. 21361 21362 `P' 21363 An unsigned 3-bit constant for 16-byte rotates and shifts 21364 21365 `R' 21366 Call operand, reg, for indirect calls 21367 21368 `S' 21369 Call operand, symbol, for relative calls. 21370 21371 `T' 21372 Call operand, const_int, for absolute calls. 21373 21374 `U' 21375 An immediate which can be loaded with the il/ila/ilh/ilhu 21376 instructions. const_int is sign extended to 128 bit. 21377 21378 `W' 21379 An immediate for shift and rotate instructions. const_int is 21380 treated as a 32 bit value. 21381 21382 `Y' 21383 An immediate for and/xor/or instructions. const_int is sign 21384 extended as a 128 bit. 21385 21386 `Z' 21387 An immediate for the `iohl' instruction. const_int is sign 21388 extended to 128 bit. 21389 21390 21391_S/390 and zSeries--`config/s390/s390.h'_ 21392 21393 `a' 21394 Address register (general purpose register except r0) 21395 21396 `c' 21397 Condition code register 21398 21399 `d' 21400 Data register (arbitrary general purpose register) 21401 21402 `f' 21403 Floating-point register 21404 21405 `I' 21406 Unsigned 8-bit constant (0-255) 21407 21408 `J' 21409 Unsigned 12-bit constant (0-4095) 21410 21411 `K' 21412 Signed 16-bit constant (-32768-32767) 21413 21414 `L' 21415 Value appropriate as displacement. 21416 `(0..4095)' 21417 for short displacement 21418 21419 `(-524288..524287)' 21420 for long displacement 21421 21422 `M' 21423 Constant integer with a value of 0x7fffffff. 21424 21425 `N' 21426 Multiple letter constraint followed by 4 parameter letters. 21427 `0..9:' 21428 number of the part counting from most to least 21429 significant 21430 21431 `H,Q:' 21432 mode of the part 21433 21434 `D,S,H:' 21435 mode of the containing operand 21436 21437 `0,F:' 21438 value of the other parts (F--all bits set) 21439 The constraint matches if the specified part of a constant 21440 has a value different from its other parts. 21441 21442 `Q' 21443 Memory reference without index register and with short 21444 displacement. 21445 21446 `R' 21447 Memory reference with index register and short displacement. 21448 21449 `S' 21450 Memory reference without index register but with long 21451 displacement. 21452 21453 `T' 21454 Memory reference with index register and long displacement. 21455 21456 `U' 21457 Pointer with short displacement. 21458 21459 `W' 21460 Pointer with long displacement. 21461 21462 `Y' 21463 Shift count operand. 21464 21465 21466_Score family--`config/score/score.h'_ 21467 21468 `d' 21469 Registers from r0 to r32. 21470 21471 `e' 21472 Registers from r0 to r16. 21473 21474 `t' 21475 r8--r11 or r22--r27 registers. 21476 21477 `h' 21478 hi register. 21479 21480 `l' 21481 lo register. 21482 21483 `x' 21484 hi + lo register. 21485 21486 `q' 21487 cnt register. 21488 21489 `y' 21490 lcb register. 21491 21492 `z' 21493 scb register. 21494 21495 `a' 21496 cnt + lcb + scb register. 21497 21498 `c' 21499 cr0--cr15 register. 21500 21501 `b' 21502 cp1 registers. 21503 21504 `f' 21505 cp2 registers. 21506 21507 `i' 21508 cp3 registers. 21509 21510 `j' 21511 cp1 + cp2 + cp3 registers. 21512 21513 `I' 21514 High 16-bit constant (32-bit constant with 16 LSBs zero). 21515 21516 `J' 21517 Unsigned 5 bit integer (in the range 0 to 31). 21518 21519 `K' 21520 Unsigned 16 bit integer (in the range 0 to 65535). 21521 21522 `L' 21523 Signed 16 bit integer (in the range -32768 to 32767). 21524 21525 `M' 21526 Unsigned 14 bit integer (in the range 0 to 16383). 21527 21528 `N' 21529 Signed 14 bit integer (in the range -8192 to 8191). 21530 21531 `Z' 21532 Any SYMBOL_REF. 21533 21534_Xstormy16--`config/stormy16/stormy16.h'_ 21535 21536 `a' 21537 Register r0. 21538 21539 `b' 21540 Register r1. 21541 21542 `c' 21543 Register r2. 21544 21545 `d' 21546 Register r8. 21547 21548 `e' 21549 Registers r0 through r7. 21550 21551 `t' 21552 Registers r0 and r1. 21553 21554 `y' 21555 The carry register. 21556 21557 `z' 21558 Registers r8 and r9. 21559 21560 `I' 21561 A constant between 0 and 3 inclusive. 21562 21563 `J' 21564 A constant that has exactly one bit set. 21565 21566 `K' 21567 A constant that has exactly one bit clear. 21568 21569 `L' 21570 A constant between 0 and 255 inclusive. 21571 21572 `M' 21573 A constant between -255 and 0 inclusive. 21574 21575 `N' 21576 A constant between -3 and 0 inclusive. 21577 21578 `O' 21579 A constant between 1 and 4 inclusive. 21580 21581 `P' 21582 A constant between -4 and -1 inclusive. 21583 21584 `Q' 21585 A memory reference that is a stack push. 21586 21587 `R' 21588 A memory reference that is a stack pop. 21589 21590 `S' 21591 A memory reference that refers to a constant address of known 21592 value. 21593 21594 `T' 21595 The register indicated by Rx (not implemented yet). 21596 21597 `U' 21598 A constant that is not between 2 and 15 inclusive. 21599 21600 `Z' 21601 The constant 0. 21602 21603 21604_TI C6X family--`config/c6x/constraints.md'_ 21605 21606 `a' 21607 Register file A (A0-A31). 21608 21609 `b' 21610 Register file B (B0-B31). 21611 21612 `A' 21613 Predicate registers in register file A (A0-A2 on C64X and 21614 higher, A1 and A2 otherwise). 21615 21616 `B' 21617 Predicate registers in register file B (B0-B2). 21618 21619 `C' 21620 A call-used register in register file B (B0-B9, B16-B31). 21621 21622 `Da' 21623 Register file A, excluding predicate registers (A3-A31, plus 21624 A0 if not C64X or higher). 21625 21626 `Db' 21627 Register file B, excluding predicate registers (B3-B31). 21628 21629 `Iu4' 21630 Integer constant in the range 0 ... 15. 21631 21632 `Iu5' 21633 Integer constant in the range 0 ... 31. 21634 21635 `In5' 21636 Integer constant in the range -31 ... 0. 21637 21638 `Is5' 21639 Integer constant in the range -16 ... 15. 21640 21641 `I5x' 21642 Integer constant that can be the operand of an ADDA or a SUBA 21643 insn. 21644 21645 `IuB' 21646 Integer constant in the range 0 ... 65535. 21647 21648 `IsB' 21649 Integer constant in the range -32768 ... 32767. 21650 21651 `IsC' 21652 Integer constant in the range -2^20 ... 2^20 - 1. 21653 21654 `Jc' 21655 Integer constant that is a valid mask for the clr instruction. 21656 21657 `Js' 21658 Integer constant that is a valid mask for the set instruction. 21659 21660 `Q' 21661 Memory location with A base register. 21662 21663 `R' 21664 Memory location with B base register. 21665 21666 `S0' 21667 On C64x+ targets, a GP-relative small data reference. 21668 21669 `S1' 21670 Any kind of `SYMBOL_REF', for use in a call address. 21671 21672 `Si' 21673 Any kind of immediate operand, unless it matches the S0 21674 constraint. 21675 21676 `T' 21677 Memory location with B base register, but not using a long 21678 offset. 21679 21680 `W' 21681 A memory operand with an address that can't be used in an 21682 unaligned access. 21683 21684 `Z' 21685 Register B14 (aka DP). 21686 21687 21688_TILE-Gx--`config/tilegx/constraints.md'_ 21689 21690 `R00' 21691 `R01' 21692 `R02' 21693 `R03' 21694 `R04' 21695 `R05' 21696 `R06' 21697 `R07' 21698 `R08' 21699 `R09' 21700 `R10' 21701 Each of these represents a register constraint for an 21702 individual register, from r0 to r10. 21703 21704 `I' 21705 Signed 8-bit integer constant. 21706 21707 `J' 21708 Signed 16-bit integer constant. 21709 21710 `K' 21711 Unsigned 16-bit integer constant. 21712 21713 `L' 21714 Integer constant that fits in one signed byte when 21715 incremented by one (-129 ... 126). 21716 21717 `m' 21718 Memory operand. If used together with `<' or `>', the 21719 operand can have postincrement which requires printing with 21720 `%In' and `%in' on TILE-Gx. For example: 21721 21722 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 21723 21724 `M' 21725 A bit mask suitable for the BFINS instruction. 21726 21727 `N' 21728 Integer constant that is a byte tiled out eight times. 21729 21730 `O' 21731 The integer zero constant. 21732 21733 `P' 21734 Integer constant that is a sign-extended byte tiled out as 21735 four shorts. 21736 21737 `Q' 21738 Integer constant that fits in one signed byte when incremented 21739 (-129 ... 126), but excluding -1. 21740 21741 `S' 21742 Integer constant that has all 1 bits consecutive and starting 21743 at bit 0. 21744 21745 `T' 21746 A 16-bit fragment of a got, tls, or pc-relative reference. 21747 21748 `U' 21749 Memory operand except postincrement. This is roughly the 21750 same as `m' when not used together with `<' or `>'. 21751 21752 `W' 21753 An 8-element vector constant with identical elements. 21754 21755 `Y' 21756 A 4-element vector constant with identical elements. 21757 21758 `Z0' 21759 The integer constant 0xffffffff. 21760 21761 `Z1' 21762 The integer constant 0xffffffff00000000. 21763 21764 21765_TILEPro--`config/tilepro/constraints.md'_ 21766 21767 `R00' 21768 `R01' 21769 `R02' 21770 `R03' 21771 `R04' 21772 `R05' 21773 `R06' 21774 `R07' 21775 `R08' 21776 `R09' 21777 `R10' 21778 Each of these represents a register constraint for an 21779 individual register, from r0 to r10. 21780 21781 `I' 21782 Signed 8-bit integer constant. 21783 21784 `J' 21785 Signed 16-bit integer constant. 21786 21787 `K' 21788 Nonzero integer constant with low 16 bits zero. 21789 21790 `L' 21791 Integer constant that fits in one signed byte when 21792 incremented by one (-129 ... 126). 21793 21794 `m' 21795 Memory operand. If used together with `<' or `>', the 21796 operand can have postincrement which requires printing with 21797 `%In' and `%in' on TILEPro. For example: 21798 21799 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 21800 21801 `M' 21802 A bit mask suitable for the MM instruction. 21803 21804 `N' 21805 Integer constant that is a byte tiled out four times. 21806 21807 `O' 21808 The integer zero constant. 21809 21810 `P' 21811 Integer constant that is a sign-extended byte tiled out as 21812 two shorts. 21813 21814 `Q' 21815 Integer constant that fits in one signed byte when incremented 21816 (-129 ... 126), but excluding -1. 21817 21818 `T' 21819 A symbolic operand, or a 16-bit fragment of a got, tls, or 21820 pc-relative reference. 21821 21822 `U' 21823 Memory operand except postincrement. This is roughly the 21824 same as `m' when not used together with `<' or `>'. 21825 21826 `W' 21827 A 4-element vector constant with identical elements. 21828 21829 `Y' 21830 A 2-element vector constant with identical elements. 21831 21832 21833_Xtensa--`config/xtensa/constraints.md'_ 21834 21835 `a' 21836 General-purpose 32-bit register 21837 21838 `b' 21839 One-bit boolean register 21840 21841 `A' 21842 MAC16 40-bit accumulator register 21843 21844 `I' 21845 Signed 12-bit integer constant, for use in MOVI instructions 21846 21847 `J' 21848 Signed 8-bit integer constant, for use in ADDI instructions 21849 21850 `K' 21851 Integer constant valid for BccI instructions 21852 21853 `L' 21854 Unsigned constant valid for BccUI instructions 21855 21856 21857 21858 21859File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 21860 2186116.8.6 Disable insn alternatives using the `enabled' attribute 21862-------------------------------------------------------------- 21863 21864The `enabled' insn attribute may be used to disable certain insn 21865alternatives for machine-specific reasons. This is useful when adding 21866new instructions to an existing pattern which are only available for 21867certain cpu architecture levels as specified with the `-march=' option. 21868 21869 If an insn alternative is disabled, then it will never be used. The 21870compiler treats the constraints for the disabled alternative as 21871unsatisfiable. 21872 21873 In order to make use of the `enabled' attribute a back end has to add 21874in the machine description files: 21875 21876 1. A definition of the `enabled' insn attribute. The attribute is 21877 defined as usual using the `define_attr' command. This definition 21878 should be based on other insn attributes and/or target flags. The 21879 `enabled' attribute is a numeric attribute and should evaluate to 21880 `(const_int 1)' for an enabled alternative and to `(const_int 0)' 21881 otherwise. 21882 21883 2. A definition of another insn attribute used to describe for what 21884 reason an insn alternative might be available or not. E.g. 21885 `cpu_facility' as in the example below. 21886 21887 3. An assignment for the second attribute to each insn definition 21888 combining instructions which are not all available under the same 21889 circumstances. (Note: It obviously only makes sense for 21890 definitions with more than one alternative. Otherwise the insn 21891 pattern should be disabled or enabled using the insn condition.) 21892 21893 E.g. the following two patterns could easily be merged using the 21894`enabled' attribute: 21895 21896 21897 (define_insn "*movdi_old" 21898 [(set (match_operand:DI 0 "register_operand" "=d") 21899 (match_operand:DI 1 "register_operand" " d"))] 21900 "!TARGET_NEW" 21901 "lgr %0,%1") 21902 21903 (define_insn "*movdi_new" 21904 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 21905 (match_operand:DI 1 "register_operand" " d,d,f"))] 21906 "TARGET_NEW" 21907 "@ 21908 lgr %0,%1 21909 ldgr %0,%1 21910 lgdr %0,%1") 21911 21912 to: 21913 21914 21915 (define_insn "*movdi_combined" 21916 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 21917 (match_operand:DI 1 "register_operand" " d,d,f"))] 21918 "" 21919 "@ 21920 lgr %0,%1 21921 ldgr %0,%1 21922 lgdr %0,%1" 21923 [(set_attr "cpu_facility" "*,new,new")]) 21924 21925 with the `enabled' attribute defined like this: 21926 21927 21928 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 21929 21930 (define_attr "enabled" "" 21931 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 21932 (and (eq_attr "cpu_facility" "new") 21933 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 21934 (const_int 1)] 21935 (const_int 0))) 21936 21937 21938File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 21939 2194016.8.7 Defining Machine-Specific Constraints 21941-------------------------------------------- 21942 21943Machine-specific constraints fall into two categories: register and 21944non-register constraints. Within the latter category, constraints 21945which allow subsets of all possible memory or address operands should 21946be specially marked, to give `reload' more information. 21947 21948 Machine-specific constraints can be given names of arbitrary length, 21949but they must be entirely composed of letters, digits, underscores 21950(`_'), and angle brackets (`< >'). Like C identifiers, they must begin 21951with a letter or underscore. 21952 21953 In order to avoid ambiguity in operand constraint strings, no 21954constraint can have a name that begins with any other constraint's 21955name. For example, if `x' is defined as a constraint name, `xy' may 21956not be, and vice versa. As a consequence of this rule, no constraint 21957may begin with one of the generic constraint letters: `E F V X g i m n 21958o p r s'. 21959 21960 Register constraints correspond directly to register classes. *Note 21961Register Classes::. There is thus not much flexibility in their 21962definitions. 21963 21964 -- MD Expression: define_register_constraint name regclass docstring 21965 All three arguments are string constants. NAME is the name of the 21966 constraint, as it will appear in `match_operand' expressions. If 21967 NAME is a multi-letter constraint its length shall be the same for 21968 all constraints starting with the same letter. REGCLASS can be 21969 either the name of the corresponding register class (*note 21970 Register Classes::), or a C expression which evaluates to the 21971 appropriate register class. If it is an expression, it must have 21972 no side effects, and it cannot look at the operand. The usual use 21973 of expressions is to map some register constraints to `NO_REGS' 21974 when the register class is not available on a given 21975 subarchitecture. 21976 21977 DOCSTRING is a sentence documenting the meaning of the constraint. 21978 Docstrings are explained further below. 21979 21980 Non-register constraints are more like predicates: the constraint 21981definition gives a Boolean expression which indicates whether the 21982constraint matches. 21983 21984 -- MD Expression: define_constraint name docstring exp 21985 The NAME and DOCSTRING arguments are the same as for 21986 `define_register_constraint', but note that the docstring comes 21987 immediately after the name for these expressions. EXP is an RTL 21988 expression, obeying the same rules as the RTL expressions in 21989 predicate definitions. *Note Defining Predicates::, for details. 21990 If it evaluates true, the constraint matches; if it evaluates 21991 false, it doesn't. Constraint expressions should indicate which 21992 RTL codes they might match, just like predicate expressions. 21993 21994 `match_test' C expressions have access to the following variables: 21995 21996 OP 21997 The RTL object defining the operand. 21998 21999 MODE 22000 The machine mode of OP. 22001 22002 IVAL 22003 `INTVAL (OP)', if OP is a `const_int'. 22004 22005 HVAL 22006 `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'. 22007 22008 LVAL 22009 `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'. 22010 22011 RVAL 22012 `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 22013 `const_double'. 22014 22015 The *VAL variables should only be used once another piece of the 22016 expression has verified that OP is the appropriate kind of RTL 22017 object. 22018 22019 Most non-register constraints should be defined with 22020`define_constraint'. The remaining two definition expressions are only 22021appropriate for constraints that should be handled specially by 22022`reload' if they fail to match. 22023 22024 -- MD Expression: define_memory_constraint name docstring exp 22025 Use this expression for constraints that match a subset of all 22026 memory operands: that is, `reload' can make them match by 22027 converting the operand to the form `(mem (reg X))', where X is a 22028 base register (from the register class specified by 22029 `BASE_REG_CLASS', *note Register Classes::). 22030 22031 For example, on the S/390, some instructions do not accept 22032 arbitrary memory references, but only those that do not make use 22033 of an index register. The constraint letter `Q' is defined to 22034 represent a memory address of this type. If `Q' is defined with 22035 `define_memory_constraint', a `Q' constraint can handle any memory 22036 operand, because `reload' knows it can simply copy the memory 22037 address into a base register if required. This is analogous to 22038 the way an `o' constraint can handle any memory operand. 22039 22040 The syntax and semantics are otherwise identical to 22041 `define_constraint'. 22042 22043 -- MD Expression: define_address_constraint name docstring exp 22044 Use this expression for constraints that match a subset of all 22045 address operands: that is, `reload' can make the constraint match 22046 by converting the operand to the form `(reg X)', again with X a 22047 base register. 22048 22049 Constraints defined with `define_address_constraint' can only be 22050 used with the `address_operand' predicate, or machine-specific 22051 predicates that work the same way. They are treated analogously to 22052 the generic `p' constraint. 22053 22054 The syntax and semantics are otherwise identical to 22055 `define_constraint'. 22056 22057 For historical reasons, names beginning with the letters `G H' are 22058reserved for constraints that match only `const_double's, and names 22059beginning with the letters `I J K L M N O P' are reserved for 22060constraints that match only `const_int's. This may change in the 22061future. For the time being, constraints with these names must be 22062written in a stylized form, so that `genpreds' can tell you did it 22063correctly: 22064 22065 (define_constraint "[GHIJKLMNOP]..." 22066 "DOC..." 22067 (and (match_code "const_int") ; `const_double' for G/H 22068 CONDITION...)) ; usually a `match_test' 22069 22070 It is fine to use names beginning with other letters for constraints 22071that match `const_double's or `const_int's. 22072 22073 Each docstring in a constraint definition should be one or more 22074complete sentences, marked up in Texinfo format. _They are currently 22075unused._ In the future they will be copied into the GCC manual, in 22076*note Machine Constraints::, replacing the hand-maintained tables 22077currently found in that section. Also, in the future the compiler may 22078use this to give more helpful diagnostics when poor choice of `asm' 22079constraints causes a reload failure. 22080 22081 If you put the pseudo-Texinfo directive `@internal' at the beginning 22082of a docstring, then (in the future) it will appear only in the 22083internals manual's version of the machine-specific constraint tables. 22084Use this for constraints that should not appear in `asm' statements. 22085 22086 22087File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 22088 2208916.8.8 Testing constraints from C 22090--------------------------------- 22091 22092It is occasionally useful to test a constraint from C code rather than 22093implicitly via the constraint string in a `match_operand'. The 22094generated file `tm_p.h' declares a few interfaces for working with 22095machine-specific constraints. None of these interfaces work with the 22096generic constraints described in *note Simple Constraints::. This may 22097change in the future. 22098 22099 *Warning:* `tm_p.h' may declare other functions that operate on 22100constraints, besides the ones documented here. Do not use those 22101functions from machine-dependent code. They exist to implement the old 22102constraint interface that machine-independent components of the 22103compiler still expect. They will change or disappear in the future. 22104 22105 Some valid constraint names are not valid C identifiers, so there is a 22106mangling scheme for referring to them from C. Constraint names that do 22107not contain angle brackets or underscores are left unchanged. 22108Underscores are doubled, each `<' is replaced with `_l', and each `>' 22109with `_g'. Here are some examples: 22110 22111 *Original* *Mangled* 22112 `x' `x' 22113 `P42x' `P42x' 22114 `P4_x' `P4__x' 22115 `P4>x' `P4_gx' 22116 `P4>>' `P4_g_g' 22117 `P4_g>' `P4__g_g' 22118 22119 Throughout this section, the variable C is either a constraint in the 22120abstract sense, or a constant from `enum constraint_num'; the variable 22121M is a mangled constraint name (usually as part of a larger identifier). 22122 22123 -- Enum: constraint_num 22124 For each machine-specific constraint, there is a corresponding 22125 enumeration constant: `CONSTRAINT_' plus the mangled name of the 22126 constraint. Functions that take an `enum constraint_num' as an 22127 argument expect one of these constants. 22128 22129 Machine-independent constraints do not have associated constants. 22130 This may change in the future. 22131 22132 -- Function: inline bool satisfies_constraint_M (rtx EXP) 22133 For each machine-specific, non-register constraint M, there is one 22134 of these functions; it returns `true' if EXP satisfies the 22135 constraint. These functions are only visible if `rtl.h' was 22136 included before `tm_p.h'. 22137 22138 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 22139 C) 22140 Like the `satisfies_constraint_M' functions, but the constraint to 22141 test is given as an argument, C. If C specifies a register 22142 constraint, this function will always return `false'. 22143 22144 -- Function: enum reg_class regclass_for_constraint (enum 22145 constraint_num C) 22146 Returns the register class associated with C. If C is not a 22147 register constraint, or those registers are not available for the 22148 currently selected subtarget, returns `NO_REGS'. 22149 22150 Here is an example use of `satisfies_constraint_M'. In peephole 22151optimizations (*note Peephole Definitions::), operand constraint 22152strings are ignored, so if there are relevant constraints, they must be 22153tested in the C condition. In the example, the optimization is applied 22154if operand 2 does _not_ satisfy the `K' constraint. (This is a 22155simplified version of a peephole definition from the i386 machine 22156description.) 22157 22158 (define_peephole2 22159 [(match_scratch:SI 3 "r") 22160 (set (match_operand:SI 0 "register_operand" "") 22161 (mult:SI (match_operand:SI 1 "memory_operand" "") 22162 (match_operand:SI 2 "immediate_operand" "")))] 22163 22164 "!satisfies_constraint_K (operands[2])" 22165 22166 [(set (match_dup 3) (match_dup 1)) 22167 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 22168 22169 "") 22170 22171 22172File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 22173 2217416.9 Standard Pattern Names For Generation 22175========================================== 22176 22177Here is a table of the instruction names that are meaningful in the RTL 22178generation pass of the compiler. Giving one of these names to an 22179instruction pattern tells the RTL generation pass that it can use the 22180pattern to accomplish a certain task. 22181 22182`movM' 22183 Here M stands for a two-letter machine mode name, in lowercase. 22184 This instruction pattern moves data with that machine mode from 22185 operand 1 to operand 0. For example, `movsi' moves full-word data. 22186 22187 If operand 0 is a `subreg' with mode M of a register whose own 22188 mode is wider than M, the effect of this instruction is to store 22189 the specified value in the part of the register that corresponds 22190 to mode M. Bits outside of M, but which are within the same 22191 target word as the `subreg' are undefined. Bits which are outside 22192 the target word are left unchanged. 22193 22194 This class of patterns is special in several ways. First of all, 22195 each of these names up to and including full word size _must_ be 22196 defined, because there is no other way to copy a datum from one 22197 place to another. If there are patterns accepting operands in 22198 larger modes, `movM' must be defined for integer modes of those 22199 sizes. 22200 22201 Second, these patterns are not used solely in the RTL generation 22202 pass. Even the reload pass can generate move insns to copy values 22203 from stack slots into temporary registers. When it does so, one 22204 of the operands is a hard register and the other is an operand 22205 that can need to be reloaded into a register. 22206 22207 Therefore, when given such a pair of operands, the pattern must 22208 generate RTL which needs no reloading and needs no temporary 22209 registers--no registers other than the operands. For example, if 22210 you support the pattern with a `define_expand', then in such a 22211 case the `define_expand' mustn't call `force_reg' or any other such 22212 function which might generate new pseudo registers. 22213 22214 This requirement exists even for subword modes on a RISC machine 22215 where fetching those modes from memory normally requires several 22216 insns and some temporary registers. 22217 22218 During reload a memory reference with an invalid address may be 22219 passed as an operand. Such an address will be replaced with a 22220 valid address later in the reload pass. In this case, nothing may 22221 be done with the address except to use it as it stands. If it is 22222 copied, it will not be replaced with a valid address. No attempt 22223 should be made to make such an address into a valid address and no 22224 routine (such as `change_address') that will do so may be called. 22225 Note that `general_operand' will fail when applied to such an 22226 address. 22227 22228 The global variable `reload_in_progress' (which must be explicitly 22229 declared if required) can be used to determine whether such special 22230 handling is required. 22231 22232 The variety of operands that have reloads depends on the rest of 22233 the machine description, but typically on a RISC machine these can 22234 only be pseudo registers that did not get hard registers, while on 22235 other machines explicit memory references will get optional 22236 reloads. 22237 22238 If a scratch register is required to move an object to or from 22239 memory, it can be allocated using `gen_reg_rtx' prior to life 22240 analysis. 22241 22242 If there are cases which need scratch registers during or after 22243 reload, you must provide an appropriate secondary_reload target 22244 hook. 22245 22246 The macro `can_create_pseudo_p' can be used to determine if it is 22247 unsafe to create new pseudo registers. If this variable is 22248 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new 22249 pseudo. 22250 22251 The constraints on a `movM' must permit moving any hard register 22252 to any other hard register provided that `HARD_REGNO_MODE_OK' 22253 permits mode M in both registers and `TARGET_REGISTER_MOVE_COST' 22254 applied to their classes returns a value of 2. 22255 22256 It is obligatory to support floating point `movM' instructions 22257 into and out of any registers that can hold fixed point values, 22258 because unions and structures (which have modes `SImode' or 22259 `DImode') can be in those registers and they may have floating 22260 point members. 22261 22262 There may also be a need to support fixed point `movM' 22263 instructions in and out of floating point registers. 22264 Unfortunately, I have forgotten why this was so, and I don't know 22265 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed 22266 point values in floating point registers, then the constraints of 22267 the fixed point `movM' instructions must be designed to avoid ever 22268 trying to reload into a floating point register. 22269 22270`reload_inM' 22271`reload_outM' 22272 These named patterns have been obsoleted by the target hook 22273 `secondary_reload'. 22274 22275 Like `movM', but used when a scratch register is required to move 22276 between operand 0 and operand 1. Operand 2 describes the scratch 22277 register. See the discussion of the `SECONDARY_RELOAD_CLASS' 22278 macro in *note Register Classes::. 22279 22280 There are special restrictions on the form of the `match_operand's 22281 used in these patterns. First, only the predicate for the reload 22282 operand is examined, i.e., `reload_in' examines operand 1, but not 22283 the predicates for operand 0 or 2. Second, there may be only one 22284 alternative in the constraints. Third, only a single register 22285 class letter may be used for the constraint; subsequent constraint 22286 letters are ignored. As a special exception, an empty constraint 22287 string matches the `ALL_REGS' register class. This may relieve 22288 ports of the burden of defining an `ALL_REGS' constraint letter 22289 just for these patterns. 22290 22291`movstrictM' 22292 Like `movM' except that if operand 0 is a `subreg' with mode M of 22293 a register whose natural mode is wider, the `movstrictM' 22294 instruction is guaranteed not to alter any of the register except 22295 the part which belongs to mode M. 22296 22297`movmisalignM' 22298 This variant of a move pattern is designed to load or store a value 22299 from a memory address that is not naturally aligned for its mode. 22300 For a store, the memory will be in operand 0; for a load, the 22301 memory will be in operand 1. The other operand is guaranteed not 22302 to be a memory, so that it's easy to tell whether this is a load 22303 or store. 22304 22305 This pattern is used by the autovectorizer, and when expanding a 22306 `MISALIGNED_INDIRECT_REF' expression. 22307 22308`load_multiple' 22309 Load several consecutive memory locations into consecutive 22310 registers. Operand 0 is the first of the consecutive registers, 22311 operand 1 is the first memory location, and operand 2 is a 22312 constant: the number of consecutive registers. 22313 22314 Define this only if the target machine really has such an 22315 instruction; do not define this if the most efficient way of 22316 loading consecutive registers from memory is to do them one at a 22317 time. 22318 22319 On some machines, there are restrictions as to which consecutive 22320 registers can be stored into memory, such as particular starting or 22321 ending register numbers or only a range of valid counts. For those 22322 machines, use a `define_expand' (*note Expander Definitions::) and 22323 make the pattern fail if the restrictions are not met. 22324 22325 Write the generated insn as a `parallel' with elements being a 22326 `set' of one register from the appropriate memory location (you may 22327 also need `use' or `clobber' elements). Use a `match_parallel' 22328 (*note RTL Template::) to recognize the insn. See `rs6000.md' for 22329 examples of the use of this insn pattern. 22330 22331`store_multiple' 22332 Similar to `load_multiple', but store several consecutive registers 22333 into consecutive memory locations. Operand 0 is the first of the 22334 consecutive memory locations, operand 1 is the first register, and 22335 operand 2 is a constant: the number of consecutive registers. 22336 22337`vec_load_lanesMN' 22338 Perform an interleaved load of several vectors from memory operand 22339 1 into register operand 0. Both operands have mode M. The 22340 register operand is viewed as holding consecutive vectors of mode 22341 N, while the memory operand is a flat array that contains the same 22342 number of elements. The operation is equivalent to: 22343 22344 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22345 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22346 for (i = 0; i < c; i++) 22347 operand0[i][j] = operand1[j * c + i]; 22348 22349 For example, `vec_load_lanestiv4hi' loads 8 16-bit values from 22350 memory into a register of mode `TI'. The register contains two 22351 consecutive vectors of mode `V4HI'. 22352 22353 This pattern can only be used if: 22354 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 22355 is true. GCC assumes that, if a target supports this kind of 22356 instruction for some mode N, it also supports unaligned loads for 22357 vectors of mode N. 22358 22359`vec_store_lanesMN' 22360 Equivalent to `vec_load_lanesMN', with the memory and register 22361 operands reversed. That is, the instruction is equivalent to: 22362 22363 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 22364 for (j = 0; j < GET_MODE_NUNITS (N); j++) 22365 for (i = 0; i < c; i++) 22366 operand0[j * c + i] = operand1[i][j]; 22367 22368 for a memory operand 0 and register operand 1. 22369 22370`vec_setM' 22371 Set given field in the vector value. Operand 0 is the vector to 22372 modify, operand 1 is new value of field and operand 2 specify the 22373 field index. 22374 22375`vec_extractM' 22376 Extract given field from the vector value. Operand 1 is the 22377 vector, operand 2 specify field index and operand 0 place to store 22378 value into. 22379 22380`vec_initM' 22381 Initialize the vector to given values. Operand 0 is the vector to 22382 initialize and operand 1 is parallel containing values for 22383 individual fields. 22384 22385`vcondMN' 22386 Output a conditional vector move. Operand 0 is the destination to 22387 receive a combination of operand 1 and operand 2, which are of 22388 mode M, dependent on the outcome of the predicate in operand 3 22389 which is a vector comparison with operands of mode N in operands 4 22390 and 5. The modes M and N should have the same size. Operand 0 22391 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 22392 computed by element-wise evaluation of the vector comparison with 22393 a truth value of all-ones and a false value of all-zeros. 22394 22395`vec_permM' 22396 Output a (variable) vector permutation. Operand 0 is the 22397 destination to receive elements from operand 1 and operand 2, 22398 which are of mode M. Operand 3 is the "selector". It is an 22399 integral mode vector of the same width and number of elements as 22400 mode M. 22401 22402 The input elements are numbered from 0 in operand 1 through 2*N-1 22403 in operand 2. The elements of the selector must be computed 22404 modulo 2*N. Note that if `rtx_equal_p(operand1, operand2)', this 22405 can be implemented with just operand 1 and selector elements 22406 modulo N. 22407 22408 In order to make things easy for a number of targets, if there is 22409 no `vec_perm' pattern for mode M, but there is for mode Q where Q 22410 is a vector of `QImode' of the same width as M, the middle-end 22411 will lower the mode M `VEC_PERM_EXPR' to mode Q. 22412 22413`vec_perm_constM' 22414 Like `vec_perm' except that the permutation is a compile-time 22415 constant. That is, operand 3, the "selector", is a `CONST_VECTOR'. 22416 22417 Some targets cannot perform a permutation with a variable selector, 22418 but can efficiently perform a constant permutation. Further, the 22419 target hook `vec_perm_ok' is queried to determine if the specific 22420 constant permutation is available efficiently; the named pattern 22421 is never expanded without `vec_perm_ok' returning true. 22422 22423 There is no need for a target to supply both `vec_permM' and 22424 `vec_perm_constM' if the former can trivially implement the 22425 operation with, say, the vector constant loaded into a register. 22426 22427`pushM1' 22428 Output a push instruction. Operand 0 is value to push. Used only 22429 when `PUSH_ROUNDING' is defined. For historical reason, this 22430 pattern may be missing and in such case an `mov' expander is used 22431 instead, with a `MEM' expression forming the push operation. The 22432 `mov' expander method is deprecated. 22433 22434`addM3' 22435 Add operand 2 and operand 1, storing the result in operand 0. All 22436 operands must have mode M. This can be used even on two-address 22437 machines, by means of constraints requiring operands 1 and 0 to be 22438 the same location. 22439 22440`ssaddM3', `usaddM3' 22441`subM3', `sssubM3', `ussubM3' 22442`mulM3', `ssmulM3', `usmulM3' 22443`divM3', `ssdivM3' 22444`udivM3', `usdivM3' 22445`modM3', `umodM3' 22446`uminM3', `umaxM3' 22447`andM3', `iorM3', `xorM3' 22448 Similar, for other arithmetic operations. 22449 22450`fmaM4' 22451 Multiply operand 2 and operand 1, then add operand 3, storing the 22452 result in operand 0 without doing an intermediate rounding step. 22453 All operands must have mode M. This pattern is used to implement 22454 the `fma', `fmaf', and `fmal' builtin functions from the ISO C99 22455 standard. 22456 22457`fmsM4' 22458 Like `fmaM4', except operand 3 subtracted from the product instead 22459 of added to the product. This is represented in the rtl as 22460 22461 (fma:M OP1 OP2 (neg:M OP3)) 22462 22463`fnmaM4' 22464 Like `fmaM4' except that the intermediate product is negated 22465 before being added to operand 3. This is represented in the rtl as 22466 22467 (fma:M (neg:M OP1) OP2 OP3) 22468 22469`fnmsM4' 22470 Like `fmsM4' except that the intermediate product is negated 22471 before subtracting operand 3. This is represented in the rtl as 22472 22473 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 22474 22475`sminM3', `smaxM3' 22476 Signed minimum and maximum operations. When used with floating 22477 point, if both operands are zeros, or if either operand is `NaN', 22478 then it is unspecified which of the two operands is returned as 22479 the result. 22480 22481`reduc_smin_M', `reduc_smax_M' 22482 Find the signed minimum/maximum of the elements of a vector. The 22483 vector is operand 1, and the scalar result is stored in the least 22484 significant bits of operand 0 (also a vector). The output and 22485 input vector should have the same modes. 22486 22487`reduc_umin_M', `reduc_umax_M' 22488 Find the unsigned minimum/maximum of the elements of a vector. The 22489 vector is operand 1, and the scalar result is stored in the least 22490 significant bits of operand 0 (also a vector). The output and 22491 input vector should have the same modes. 22492 22493`reduc_splus_M' 22494 Compute the sum of the signed elements of a vector. The vector is 22495 operand 1, and the scalar result is stored in the least 22496 significant bits of operand 0 (also a vector). The output and 22497 input vector should have the same modes. 22498 22499`reduc_uplus_M' 22500 Compute the sum of the unsigned elements of a vector. The vector 22501 is operand 1, and the scalar result is stored in the least 22502 significant bits of operand 0 (also a vector). The output and 22503 input vector should have the same modes. 22504 22505`sdot_prodM' 22506 22507`udot_prodM' 22508 Compute the sum of the products of two signed/unsigned elements. 22509 Operand 1 and operand 2 are of the same mode. Their product, which 22510 is of a wider mode, is computed and added to operand 3. Operand 3 22511 is of a mode equal or wider than the mode of the product. The 22512 result is placed in operand 0, which is of the same mode as 22513 operand 3. 22514 22515`ssum_widenM3' 22516 22517`usum_widenM3' 22518 Operands 0 and 2 are of the same mode, which is wider than the 22519 mode of operand 1. Add operand 1 to operand 2 and place the 22520 widened result in operand 0. (This is used express accumulation of 22521 elements into an accumulator of a wider mode.) 22522 22523`vec_shl_M', `vec_shr_M' 22524 Whole vector left/right shift in bits. Operand 1 is a vector to 22525 be shifted. Operand 2 is an integer shift amount in bits. 22526 Operand 0 is where the resulting shifted vector is stored. The 22527 output and input vectors should have the same modes. 22528 22529`vec_pack_trunc_M' 22530 Narrow (demote) and merge the elements of two vectors. Operands 1 22531 and 2 are vectors of the same mode having N integral or floating 22532 point elements of size S. Operand 0 is the resulting vector in 22533 which 2*N elements of size N/2 are concatenated after narrowing 22534 them down using truncation. 22535 22536`vec_pack_ssat_M', `vec_pack_usat_M' 22537 Narrow (demote) and merge the elements of two vectors. Operands 1 22538 and 2 are vectors of the same mode having N integral elements of 22539 size S. Operand 0 is the resulting vector in which the elements 22540 of the two input vectors are concatenated after narrowing them 22541 down using signed/unsigned saturating arithmetic. 22542 22543`vec_pack_sfix_trunc_M', `vec_pack_ufix_trunc_M' 22544 Narrow, convert to signed/unsigned integral type and merge the 22545 elements of two vectors. Operands 1 and 2 are vectors of the same 22546 mode having N floating point elements of size S. Operand 0 is the 22547 resulting vector in which 2*N elements of size N/2 are 22548 concatenated. 22549 22550`vec_unpacks_hi_M', `vec_unpacks_lo_M' 22551 Extract and widen (promote) the high/low part of a vector of signed 22552 integral or floating point elements. The input vector (operand 1) 22553 has N elements of size S. Widen (promote) the high/low elements 22554 of the vector using signed or floating point extension and place 22555 the resulting N/2 values of size 2*S in the output vector (operand 22556 0). 22557 22558`vec_unpacku_hi_M', `vec_unpacku_lo_M' 22559 Extract and widen (promote) the high/low part of a vector of 22560 unsigned integral elements. The input vector (operand 1) has N 22561 elements of size S. Widen (promote) the high/low elements of the 22562 vector using zero extension and place the resulting N/2 values of 22563 size 2*S in the output vector (operand 0). 22564 22565`vec_unpacks_float_hi_M', `vec_unpacks_float_lo_M' 22566`vec_unpacku_float_hi_M', `vec_unpacku_float_lo_M' 22567 Extract, convert to floating point type and widen the high/low 22568 part of a vector of signed/unsigned integral elements. The input 22569 vector (operand 1) has N elements of size S. Convert the high/low 22570 elements of the vector using floating point conversion and place 22571 the resulting N/2 values of size 2*S in the output vector (operand 22572 0). 22573 22574`vec_widen_umult_hi_M', `vec_widen_umult_lo_M' 22575`vec_widen_smult_hi_M', `vec_widen_smult_lo_M' 22576`vec_widen_umult_even_M', `vec_widen_umult_odd_M' 22577`vec_widen_smult_even_M', `vec_widen_smult_odd_M' 22578 Signed/Unsigned widening multiplication. The two inputs (operands 22579 1 and 2) are vectors with N signed/unsigned elements of size S. 22580 Multiply the high/low or even/odd elements of the two vectors, and 22581 put the N/2 products of size 2*S in the output vector (operand 0). 22582 22583`vec_widen_ushiftl_hi_M', `vec_widen_ushiftl_lo_M' 22584`vec_widen_sshiftl_hi_M', `vec_widen_sshiftl_lo_M' 22585 Signed/Unsigned widening shift left. The first input (operand 1) 22586 is a vector with N signed/unsigned elements of size S. Operand 2 22587 is a constant. Shift the high/low elements of operand 1, and put 22588 the N/2 results of size 2*S in the output vector (operand 0). 22589 22590`mulhisi3' 22591 Multiply operands 1 and 2, which have mode `HImode', and store a 22592 `SImode' product in operand 0. 22593 22594`mulqihi3', `mulsidi3' 22595 Similar widening-multiplication instructions of other widths. 22596 22597`umulqihi3', `umulhisi3', `umulsidi3' 22598 Similar widening-multiplication instructions that do unsigned 22599 multiplication. 22600 22601`usmulqihi3', `usmulhisi3', `usmulsidi3' 22602 Similar widening-multiplication instructions that interpret the 22603 first operand as unsigned and the second operand as signed, then 22604 do a signed multiplication. 22605 22606`smulM3_highpart' 22607 Perform a signed multiplication of operands 1 and 2, which have 22608 mode M, and store the most significant half of the product in 22609 operand 0. The least significant half of the product is discarded. 22610 22611`umulM3_highpart' 22612 Similar, but the multiplication is unsigned. 22613 22614`maddMN4' 22615 Multiply operands 1 and 2, sign-extend them to mode N, add operand 22616 3, and store the result in operand 0. Operands 1 and 2 have mode 22617 M and operands 0 and 3 have mode N. Both modes must be integer or 22618 fixed-point modes and N must be twice the size of M. 22619 22620 In other words, `maddMN4' is like `mulMN3' except that it also 22621 adds operand 3. 22622 22623 These instructions are not allowed to `FAIL'. 22624 22625`umaddMN4' 22626 Like `maddMN4', but zero-extend the multiplication operands 22627 instead of sign-extending them. 22628 22629`ssmaddMN4' 22630 Like `maddMN4', but all involved operations must be 22631 signed-saturating. 22632 22633`usmaddMN4' 22634 Like `umaddMN4', but all involved operations must be 22635 unsigned-saturating. 22636 22637`msubMN4' 22638 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 22639 result from operand 3, and store the result in operand 0. 22640 Operands 1 and 2 have mode M and operands 0 and 3 have mode N. 22641 Both modes must be integer or fixed-point modes and N must be twice 22642 the size of M. 22643 22644 In other words, `msubMN4' is like `mulMN3' except that it also 22645 subtracts the result from operand 3. 22646 22647 These instructions are not allowed to `FAIL'. 22648 22649`umsubMN4' 22650 Like `msubMN4', but zero-extend the multiplication operands 22651 instead of sign-extending them. 22652 22653`ssmsubMN4' 22654 Like `msubMN4', but all involved operations must be 22655 signed-saturating. 22656 22657`usmsubMN4' 22658 Like `umsubMN4', but all involved operations must be 22659 unsigned-saturating. 22660 22661`divmodM4' 22662 Signed division that produces both a quotient and a remainder. 22663 Operand 1 is divided by operand 2 to produce a quotient stored in 22664 operand 0 and a remainder stored in operand 3. 22665 22666 For machines with an instruction that produces both a quotient and 22667 a remainder, provide a pattern for `divmodM4' but do not provide 22668 patterns for `divM3' and `modM3'. This allows optimization in the 22669 relatively common case when both the quotient and remainder are 22670 computed. 22671 22672 If an instruction that just produces a quotient or just a remainder 22673 exists and is more efficient than the instruction that produces 22674 both, write the output routine of `divmodM4' to call 22675 `find_reg_note' and look for a `REG_UNUSED' note on the quotient 22676 or remainder and generate the appropriate instruction. 22677 22678`udivmodM4' 22679 Similar, but does unsigned division. 22680 22681`ashlM3', `ssashlM3', `usashlM3' 22682 Arithmetic-shift operand 1 left by a number of bits specified by 22683 operand 2, and store the result in operand 0. Here M is the mode 22684 of operand 0 and operand 1; operand 2's mode is specified by the 22685 instruction pattern, and the compiler will convert the operand to 22686 that mode before generating the instruction. The meaning of 22687 out-of-range shift counts can optionally be specified by 22688 `TARGET_SHIFT_TRUNCATION_MASK'. *Note 22689 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 22690 22691`ashrM3', `lshrM3', `rotlM3', `rotrM3' 22692 Other shift and rotate instructions, analogous to the `ashlM3' 22693 instructions. Operand 2 is always a scalar type. 22694 22695`vashlM3', `vashrM3', `vlshrM3', `vrotlM3', `vrotrM3' 22696 Vector shift and rotate instructions that take vectors as operand 2 22697 instead of a scalar type. 22698 22699`bswapM2' 22700 Reverse the order of bytes of operand 1 and store the result in 22701 operand 0. 22702 22703`negM2', `ssnegM2', `usnegM2' 22704 Negate operand 1 and store the result in operand 0. 22705 22706`absM2' 22707 Store the absolute value of operand 1 into operand 0. 22708 22709`sqrtM2' 22710 Store the square root of operand 1 into operand 0. 22711 22712 The `sqrt' built-in function of C always uses the mode which 22713 corresponds to the C data type `double' and the `sqrtf' built-in 22714 function uses the mode which corresponds to the C data type 22715 `float'. 22716 22717`fmodM3' 22718 Store the remainder of dividing operand 1 by operand 2 into 22719 operand 0, rounded towards zero to an integer. 22720 22721 The `fmod' built-in function of C always uses the mode which 22722 corresponds to the C data type `double' and the `fmodf' built-in 22723 function uses the mode which corresponds to the C data type 22724 `float'. 22725 22726`remainderM3' 22727 Store the remainder of dividing operand 1 by operand 2 into 22728 operand 0, rounded to the nearest integer. 22729 22730 The `remainder' built-in function of C always uses the mode which 22731 corresponds to the C data type `double' and the `remainderf' 22732 built-in function uses the mode which corresponds to the C data 22733 type `float'. 22734 22735`cosM2' 22736 Store the cosine of operand 1 into operand 0. 22737 22738 The `cos' built-in function of C always uses the mode which 22739 corresponds to the C data type `double' and the `cosf' built-in 22740 function uses the mode which corresponds to the C data type 22741 `float'. 22742 22743`sinM2' 22744 Store the sine of operand 1 into operand 0. 22745 22746 The `sin' built-in function of C always uses the mode which 22747 corresponds to the C data type `double' and the `sinf' built-in 22748 function uses the mode which corresponds to the C data type 22749 `float'. 22750 22751`sincosM3' 22752 Store the cosine of operand 2 into operand 0 and the sine of 22753 operand 2 into operand 1. 22754 22755 The `sin' and `cos' built-in functions of C always use the mode 22756 which corresponds to the C data type `double' and the `sinf' and 22757 `cosf' built-in function use the mode which corresponds to the C 22758 data type `float'. Targets that can calculate the sine and cosine 22759 simultaneously can implement this pattern as opposed to 22760 implementing individual `sinM2' and `cosM2' patterns. The `sin' 22761 and `cos' built-in functions will then be expanded to the 22762 `sincosM3' pattern, with one of the output values left unused. 22763 22764`expM2' 22765 Store the exponential of operand 1 into operand 0. 22766 22767 The `exp' built-in function of C always uses the mode which 22768 corresponds to the C data type `double' and the `expf' built-in 22769 function uses the mode which corresponds to the C data type 22770 `float'. 22771 22772`logM2' 22773 Store the natural logarithm of operand 1 into operand 0. 22774 22775 The `log' built-in function of C always uses the mode which 22776 corresponds to the C data type `double' and the `logf' built-in 22777 function uses the mode which corresponds to the C data type 22778 `float'. 22779 22780`powM3' 22781 Store the value of operand 1 raised to the exponent operand 2 into 22782 operand 0. 22783 22784 The `pow' built-in function of C always uses the mode which 22785 corresponds to the C data type `double' and the `powf' built-in 22786 function uses the mode which corresponds to the C data type 22787 `float'. 22788 22789`atan2M3' 22790 Store the arc tangent (inverse tangent) of operand 1 divided by 22791 operand 2 into operand 0, using the signs of both arguments to 22792 determine the quadrant of the result. 22793 22794 The `atan2' built-in function of C always uses the mode which 22795 corresponds to the C data type `double' and the `atan2f' built-in 22796 function uses the mode which corresponds to the C data type 22797 `float'. 22798 22799`floorM2' 22800 Store the largest integral value not greater than argument. 22801 22802 The `floor' built-in function of C always uses the mode which 22803 corresponds to the C data type `double' and the `floorf' built-in 22804 function uses the mode which corresponds to the C data type 22805 `float'. 22806 22807`btruncM2' 22808 Store the argument rounded to integer towards zero. 22809 22810 The `trunc' built-in function of C always uses the mode which 22811 corresponds to the C data type `double' and the `truncf' built-in 22812 function uses the mode which corresponds to the C data type 22813 `float'. 22814 22815`roundM2' 22816 Store the argument rounded to integer away from zero. 22817 22818 The `round' built-in function of C always uses the mode which 22819 corresponds to the C data type `double' and the `roundf' built-in 22820 function uses the mode which corresponds to the C data type 22821 `float'. 22822 22823`ceilM2' 22824 Store the argument rounded to integer away from zero. 22825 22826 The `ceil' built-in function of C always uses the mode which 22827 corresponds to the C data type `double' and the `ceilf' built-in 22828 function uses the mode which corresponds to the C data type 22829 `float'. 22830 22831`nearbyintM2' 22832 Store the argument rounded according to the default rounding mode 22833 22834 The `nearbyint' built-in function of C always uses the mode which 22835 corresponds to the C data type `double' and the `nearbyintf' 22836 built-in function uses the mode which corresponds to the C data 22837 type `float'. 22838 22839`rintM2' 22840 Store the argument rounded according to the default rounding mode 22841 and raise the inexact exception when the result differs in value 22842 from the argument 22843 22844 The `rint' built-in function of C always uses the mode which 22845 corresponds to the C data type `double' and the `rintf' built-in 22846 function uses the mode which corresponds to the C data type 22847 `float'. 22848 22849`lrintMN2' 22850 Convert operand 1 (valid for floating point mode M) to fixed point 22851 mode N as a signed number according to the current rounding mode 22852 and store in operand 0 (which has mode N). 22853 22854`lroundMN2' 22855 Convert operand 1 (valid for floating point mode M) to fixed point 22856 mode N as a signed number rounding to nearest and away from zero 22857 and store in operand 0 (which has mode N). 22858 22859`lfloorMN2' 22860 Convert operand 1 (valid for floating point mode M) to fixed point 22861 mode N as a signed number rounding down and store in operand 0 22862 (which has mode N). 22863 22864`lceilMN2' 22865 Convert operand 1 (valid for floating point mode M) to fixed point 22866 mode N as a signed number rounding up and store in operand 0 22867 (which has mode N). 22868 22869`copysignM3' 22870 Store a value with the magnitude of operand 1 and the sign of 22871 operand 2 into operand 0. 22872 22873 The `copysign' built-in function of C always uses the mode which 22874 corresponds to the C data type `double' and the `copysignf' 22875 built-in function uses the mode which corresponds to the C data 22876 type `float'. 22877 22878`ffsM2' 22879 Store into operand 0 one plus the index of the least significant 22880 1-bit of operand 1. If operand 1 is zero, store zero. M is the 22881 mode of operand 0; operand 1's mode is specified by the instruction 22882 pattern, and the compiler will convert the operand to that mode 22883 before generating the instruction. 22884 22885 The `ffs' built-in function of C always uses the mode which 22886 corresponds to the C data type `int'. 22887 22888`clzM2' 22889 Store into operand 0 the number of leading 0-bits in X, starting 22890 at the most significant bit position. If X is 0, the 22891 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 22892 result is undefined or has a useful value. M is the mode of 22893 operand 0; operand 1's mode is specified by the instruction 22894 pattern, and the compiler will convert the operand to that mode 22895 before generating the instruction. 22896 22897`ctzM2' 22898 Store into operand 0 the number of trailing 0-bits in X, starting 22899 at the least significant bit position. If X is 0, the 22900 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 22901 result is undefined or has a useful value. M is the mode of 22902 operand 0; operand 1's mode is specified by the instruction 22903 pattern, and the compiler will convert the operand to that mode 22904 before generating the instruction. 22905 22906`popcountM2' 22907 Store into operand 0 the number of 1-bits in X. M is the mode of 22908 operand 0; operand 1's mode is specified by the instruction 22909 pattern, and the compiler will convert the operand to that mode 22910 before generating the instruction. 22911 22912`parityM2' 22913 Store into operand 0 the parity of X, i.e. the number of 1-bits in 22914 X modulo 2. M is the mode of operand 0; operand 1's mode is 22915 specified by the instruction pattern, and the compiler will convert 22916 the operand to that mode before generating the instruction. 22917 22918`one_cmplM2' 22919 Store the bitwise-complement of operand 1 into operand 0. 22920 22921`movmemM' 22922 Block move instruction. The destination and source blocks of 22923 memory are the first two operands, and both are `mem:BLK's with an 22924 address in mode `Pmode'. 22925 22926 The number of bytes to move is the third operand, in mode M. 22927 Usually, you specify `word_mode' for M. However, if you can 22928 generate better code knowing the range of valid lengths is smaller 22929 than those representable in a full word, you should provide a 22930 pattern with a mode corresponding to the range of values you can 22931 handle efficiently (e.g., `QImode' for values in the range 0-127; 22932 note we avoid numbers that appear negative) and also a pattern 22933 with `word_mode'. 22934 22935 The fourth operand is the known shared alignment of the source and 22936 destination, in the form of a `const_int' rtx. Thus, if the 22937 compiler knows that both source and destination are word-aligned, 22938 it may provide the value 4 for this operand. 22939 22940 Optional operands 5 and 6 specify expected alignment and size of 22941 block respectively. The expected alignment differs from alignment 22942 in operand 4 in a way that the blocks are not required to be 22943 aligned according to it in all cases. This expected alignment is 22944 also in bytes, just like operand 4. Expected size, when unknown, 22945 is set to `(const_int -1)'. 22946 22947 Descriptions of multiple `movmemM' patterns can only be beneficial 22948 if the patterns for smaller modes have fewer restrictions on their 22949 first, second and fourth operands. Note that the mode M in 22950 `movmemM' does not impose any restriction on the mode of 22951 individually moved data units in the block. 22952 22953 These patterns need not give special consideration to the 22954 possibility that the source and destination strings might overlap. 22955 22956`movstr' 22957 String copy instruction, with `stpcpy' semantics. Operand 0 is an 22958 output operand in mode `Pmode'. The addresses of the destination 22959 and source strings are operands 1 and 2, and both are `mem:BLK's 22960 with addresses in mode `Pmode'. The execution of the expansion of 22961 this pattern should store in operand 0 the address in which the 22962 `NUL' terminator was stored in the destination string. 22963 22964`setmemM' 22965 Block set instruction. The destination string is the first 22966 operand, given as a `mem:BLK' whose address is in mode `Pmode'. 22967 The number of bytes to set is the second operand, in mode M. The 22968 value to initialize the memory with is the third operand. Targets 22969 that only support the clearing of memory should reject any value 22970 that is not the constant 0. See `movmemM' for a discussion of the 22971 choice of mode. 22972 22973 The fourth operand is the known alignment of the destination, in 22974 the form of a `const_int' rtx. Thus, if the compiler knows that 22975 the destination is word-aligned, it may provide the value 4 for 22976 this operand. 22977 22978 Optional operands 5 and 6 specify expected alignment and size of 22979 block respectively. The expected alignment differs from alignment 22980 in operand 4 in a way that the blocks are not required to be 22981 aligned according to it in all cases. This expected alignment is 22982 also in bytes, just like operand 4. Expected size, when unknown, 22983 is set to `(const_int -1)'. 22984 22985 The use for multiple `setmemM' is as for `movmemM'. 22986 22987`cmpstrnM' 22988 String compare instruction, with five operands. Operand 0 is the 22989 output; it has mode M. The remaining four operands are like the 22990 operands of `movmemM'. The two memory blocks specified are 22991 compared byte by byte in lexicographic order starting at the 22992 beginning of each string. The instruction is not allowed to 22993 prefetch more than one byte at a time since either string may end 22994 in the first byte and reading past that may access an invalid page 22995 or segment and cause a fault. The comparison terminates early if 22996 the fetched bytes are different or if they are equal to zero. The 22997 effect of the instruction is to store a value in operand 0 whose 22998 sign indicates the result of the comparison. 22999 23000`cmpstrM' 23001 String compare instruction, without known maximum length. Operand 23002 0 is the output; it has mode M. The second and third operand are 23003 the blocks of memory to be compared; both are `mem:BLK' with an 23004 address in mode `Pmode'. 23005 23006 The fourth operand is the known shared alignment of the source and 23007 destination, in the form of a `const_int' rtx. Thus, if the 23008 compiler knows that both source and destination are word-aligned, 23009 it may provide the value 4 for this operand. 23010 23011 The two memory blocks specified are compared byte by byte in 23012 lexicographic order starting at the beginning of each string. The 23013 instruction is not allowed to prefetch more than one byte at a 23014 time since either string may end in the first byte and reading 23015 past that may access an invalid page or segment and cause a fault. 23016 The comparison will terminate when the fetched bytes are different 23017 or if they are equal to zero. The effect of the instruction is to 23018 store a value in operand 0 whose sign indicates the result of the 23019 comparison. 23020 23021`cmpmemM' 23022 Block compare instruction, with five operands like the operands of 23023 `cmpstrM'. The two memory blocks specified are compared byte by 23024 byte in lexicographic order starting at the beginning of each 23025 block. Unlike `cmpstrM' the instruction can prefetch any bytes in 23026 the two memory blocks. Also unlike `cmpstrM' the comparison will 23027 not stop if both bytes are zero. The effect of the instruction is 23028 to store a value in operand 0 whose sign indicates the result of 23029 the comparison. 23030 23031`strlenM' 23032 Compute the length of a string, with three operands. Operand 0 is 23033 the result (of mode M), operand 1 is a `mem' referring to the 23034 first character of the string, operand 2 is the character to 23035 search for (normally zero), and operand 3 is a constant describing 23036 the known alignment of the beginning of the string. 23037 23038`floatMN2' 23039 Convert signed integer operand 1 (valid for fixed point mode M) to 23040 floating point mode N and store in operand 0 (which has mode N). 23041 23042`floatunsMN2' 23043 Convert unsigned integer operand 1 (valid for fixed point mode M) 23044 to floating point mode N and store in operand 0 (which has mode N). 23045 23046`fixMN2' 23047 Convert operand 1 (valid for floating point mode M) to fixed point 23048 mode N as a signed number and store in operand 0 (which has mode 23049 N). This instruction's result is defined only when the value of 23050 operand 1 is an integer. 23051 23052 If the machine description defines this pattern, it also needs to 23053 define the `ftrunc' pattern. 23054 23055`fixunsMN2' 23056 Convert operand 1 (valid for floating point mode M) to fixed point 23057 mode N as an unsigned number and store in operand 0 (which has 23058 mode N). This instruction's result is defined only when the value 23059 of operand 1 is an integer. 23060 23061`ftruncM2' 23062 Convert operand 1 (valid for floating point mode M) to an integer 23063 value, still represented in floating point mode M, and store it in 23064 operand 0 (valid for floating point mode M). 23065 23066`fix_truncMN2' 23067 Like `fixMN2' but works for any floating point value of mode M by 23068 converting the value to an integer. 23069 23070`fixuns_truncMN2' 23071 Like `fixunsMN2' but works for any floating point value of mode M 23072 by converting the value to an integer. 23073 23074`truncMN2' 23075 Truncate operand 1 (valid for mode M) to mode N and store in 23076 operand 0 (which has mode N). Both modes must be fixed point or 23077 both floating point. 23078 23079`extendMN2' 23080 Sign-extend operand 1 (valid for mode M) to mode N and store in 23081 operand 0 (which has mode N). Both modes must be fixed point or 23082 both floating point. 23083 23084`zero_extendMN2' 23085 Zero-extend operand 1 (valid for mode M) to mode N and store in 23086 operand 0 (which has mode N). Both modes must be fixed point. 23087 23088`fractMN2' 23089 Convert operand 1 of mode M to mode N and store in operand 0 23090 (which has mode N). Mode M and mode N could be fixed-point to 23091 fixed-point, signed integer to fixed-point, fixed-point to signed 23092 integer, floating-point to fixed-point, or fixed-point to 23093 floating-point. When overflows or underflows happen, the results 23094 are undefined. 23095 23096`satfractMN2' 23097 Convert operand 1 of mode M to mode N and store in operand 0 23098 (which has mode N). Mode M and mode N could be fixed-point to 23099 fixed-point, signed integer to fixed-point, or floating-point to 23100 fixed-point. When overflows or underflows happen, the instruction 23101 saturates the results to the maximum or the minimum. 23102 23103`fractunsMN2' 23104 Convert operand 1 of mode M to mode N and store in operand 0 23105 (which has mode N). Mode M and mode N could be unsigned integer 23106 to fixed-point, or fixed-point to unsigned integer. When 23107 overflows or underflows happen, the results are undefined. 23108 23109`satfractunsMN2' 23110 Convert unsigned integer operand 1 of mode M to fixed-point mode N 23111 and store in operand 0 (which has mode N). When overflows or 23112 underflows happen, the instruction saturates the results to the 23113 maximum or the minimum. 23114 23115`extvM' 23116 Extract a bit-field from register operand 1, sign-extend it, and 23117 store it in operand 0. Operand 2 specifies the width of the field 23118 in bits and operand 3 the starting bit, which counts from the most 23119 significant bit if `BITS_BIG_ENDIAN' is true and from the least 23120 significant bit otherwise. 23121 23122 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 23123 target-specific mode. 23124 23125`extvmisalignM' 23126 Extract a bit-field from memory operand 1, sign extend it, and 23127 store it in operand 0. Operand 2 specifies the width in bits and 23128 operand 3 the starting bit. The starting bit is always somewhere 23129 in the first byte of operand 1; it counts from the most 23130 significant bit if `BITS_BIG_ENDIAN' is true and from the least 23131 significant bit otherwise. 23132 23133 Operand 0 has mode M while operand 1 has `BLK' mode. Operands 2 23134 and 3 have a target-specific mode. 23135 23136 The instruction must not read beyond the last byte of the 23137 bit-field. 23138 23139`extzvM' 23140 Like `extvM' except that the bit-field value is zero-extended. 23141 23142`extzvmisalignM' 23143 Like `extvmisalignM' except that the bit-field value is 23144 zero-extended. 23145 23146`insvM' 23147 Insert operand 3 into a bit-field of register operand 0. Operand 1 23148 specifies the width of the field in bits and operand 2 the 23149 starting bit, which counts from the most significant bit if 23150 `BITS_BIG_ENDIAN' is true and from the least significant bit 23151 otherwise. 23152 23153 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 23154 target-specific mode. 23155 23156`insvmisalignM' 23157 Insert operand 3 into a bit-field of memory operand 0. Operand 1 23158 specifies the width of the field in bits and operand 2 the 23159 starting bit. The starting bit is always somewhere in the first 23160 byte of operand 0; it counts from the most significant bit if 23161 `BITS_BIG_ENDIAN' is true and from the least significant bit 23162 otherwise. 23163 23164 Operand 3 has mode M while operand 0 has `BLK' mode. Operands 1 23165 and 2 have a target-specific mode. 23166 23167 The instruction must not read or write beyond the last byte of the 23168 bit-field. 23169 23170`extv' 23171 Extract a bit-field from operand 1 (a register or memory operand), 23172 where operand 2 specifies the width in bits and operand 3 the 23173 starting bit, and store it in operand 0. Operand 0 must have mode 23174 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; 23175 often `word_mode' is allowed only for registers. Operands 2 and 3 23176 must be valid for `word_mode'. 23177 23178 The RTL generation pass generates this instruction only with 23179 constants for operands 2 and 3 and the constant is never zero for 23180 operand 2. 23181 23182 The bit-field value is sign-extended to a full word integer before 23183 it is stored in operand 0. 23184 23185 This pattern is deprecated; please use `extvM' and `extvmisalignM' 23186 instead. 23187 23188`extzv' 23189 Like `extv' except that the bit-field value is zero-extended. 23190 23191 This pattern is deprecated; please use `extzvM' and 23192 `extzvmisalignM' instead. 23193 23194`insv' 23195 Store operand 3 (which must be valid for `word_mode') into a 23196 bit-field in operand 0, where operand 1 specifies the width in 23197 bits and operand 2 the starting bit. Operand 0 may have mode 23198 `byte_mode' or `word_mode'; often `word_mode' is allowed only for 23199 registers. Operands 1 and 2 must be valid for `word_mode'. 23200 23201 The RTL generation pass generates this instruction only with 23202 constants for operands 1 and 2 and the constant is never zero for 23203 operand 1. 23204 23205 This pattern is deprecated; please use `insvM' and `insvmisalignM' 23206 instead. 23207 23208`movMODEcc' 23209 Conditionally move operand 2 or operand 3 into operand 0 according 23210 to the comparison in operand 1. If the comparison is true, 23211 operand 2 is moved into operand 0, otherwise operand 3 is moved. 23212 23213 The mode of the operands being compared need not be the same as 23214 the operands being moved. Some machines, sparc64 for example, 23215 have instructions that conditionally move an integer value based 23216 on the floating point condition codes and vice versa. 23217 23218 If the machine does not have conditional move instructions, do not 23219 define these patterns. 23220 23221`addMODEcc' 23222 Similar to `movMODEcc' but for conditional addition. Conditionally 23223 move operand 2 or (operands 2 + operand 3) into operand 0 23224 according to the comparison in operand 1. If the comparison is 23225 false, operand 2 is moved into operand 0, otherwise (operand 2 + 23226 operand 3) is moved. 23227 23228`cstoreMODE4' 23229 Store zero or nonzero in operand 0 according to whether a 23230 comparison is true. Operand 1 is a comparison operator. Operand 23231 2 and operand 3 are the first and second operand of the 23232 comparison, respectively. You specify the mode that operand 0 23233 must have when you write the `match_operand' expression. The 23234 compiler automatically sees which mode you have used and supplies 23235 an operand of that mode. 23236 23237 The value stored for a true condition must have 1 as its low bit, 23238 or else must be negative. Otherwise the instruction is not 23239 suitable and you should omit it from the machine description. You 23240 describe to the compiler exactly which value is stored by defining 23241 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description 23242 cannot be found that can be used for all the possible comparison 23243 operators, you should pick one and use a `define_expand' to map 23244 all results onto the one you chose. 23245 23246 These operations may `FAIL', but should do so only in relatively 23247 uncommon cases; if they would `FAIL' for common cases involving 23248 integer comparisons, it is best to restrict the predicates to not 23249 allow these operands. Likewise if a given comparison operator will 23250 always fail, independent of the operands (for floating-point 23251 modes, the `ordered_comparison_operator' predicate is often useful 23252 in this case). 23253 23254 If this pattern is omitted, the compiler will generate a 23255 conditional branch--for example, it may copy a constant one to the 23256 target and branching around an assignment of zero to the 23257 target--or a libcall. If the predicate for operand 1 only rejects 23258 some operators, it will also try reordering the operands and/or 23259 inverting the result value (e.g. by an exclusive OR). These 23260 possibilities could be cheaper or equivalent to the instructions 23261 used for the `cstoreMODE4' pattern followed by those required to 23262 convert a positive result from `STORE_FLAG_VALUE' to 1; in this 23263 case, you can and should make operand 1's predicate reject some 23264 operators in the `cstoreMODE4' pattern, or remove the pattern 23265 altogether from the machine description. 23266 23267`cbranchMODE4' 23268 Conditional branch instruction combined with a compare instruction. 23269 Operand 0 is a comparison operator. Operand 1 and operand 2 are 23270 the first and second operands of the comparison, respectively. 23271 Operand 3 is a `label_ref' that refers to the label to jump to. 23272 23273`jump' 23274 A jump inside a function; an unconditional branch. Operand 0 is 23275 the `label_ref' of the label to jump to. This pattern name is 23276 mandatory on all machines. 23277 23278`call' 23279 Subroutine call instruction returning no value. Operand 0 is the 23280 function to call; operand 1 is the number of bytes of arguments 23281 pushed as a `const_int'; operand 2 is the number of registers used 23282 as operands. 23283 23284 On most machines, operand 2 is not actually stored into the RTL 23285 pattern. It is supplied for the sake of some RISC machines which 23286 need to put this information into the assembler code; they can put 23287 it in the RTL instead of operand 1. 23288 23289 Operand 0 should be a `mem' RTX whose address is the address of the 23290 function. Note, however, that this address can be a `symbol_ref' 23291 expression even if it would not be a legitimate memory address on 23292 the target machine. If it is also not a valid argument for a call 23293 instruction, the pattern for this operation should be a 23294 `define_expand' (*note Expander Definitions::) that places the 23295 address into a register and uses that register in the call 23296 instruction. 23297 23298`call_value' 23299 Subroutine call instruction returning a value. Operand 0 is the 23300 hard register in which the value is returned. There are three more 23301 operands, the same as the three operands of the `call' instruction 23302 (but with numbers increased by one). 23303 23304 Subroutines that return `BLKmode' objects use the `call' insn. 23305 23306`call_pop', `call_value_pop' 23307 Similar to `call' and `call_value', except used if defined and if 23308 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that 23309 contains both the function call and a `set' to indicate the 23310 adjustment made to the frame pointer. 23311 23312 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of 23313 these patterns increases the number of functions for which the 23314 frame pointer can be eliminated, if desired. 23315 23316`untyped_call' 23317 Subroutine call instruction returning a value of any type. 23318 Operand 0 is the function to call; operand 1 is a memory location 23319 where the result of calling the function is to be stored; operand 23320 2 is a `parallel' expression where each element is a `set' 23321 expression that indicates the saving of a function return value 23322 into the result block. 23323 23324 This instruction pattern should be defined to support 23325 `__builtin_apply' on machines where special instructions are needed 23326 to call a subroutine with arbitrary arguments or to save the value 23327 returned. This instruction pattern is required on machines that 23328 have multiple registers that can hold a return value (i.e. 23329 `FUNCTION_VALUE_REGNO_P' is true for more than one register). 23330 23331`return' 23332 Subroutine return instruction. This instruction pattern name 23333 should be defined only if a single instruction can do all the work 23334 of returning from a function. 23335 23336 Like the `movM' patterns, this pattern is also used after the RTL 23337 generation phase. In this case it is to support machines where 23338 multiple instructions are usually needed to return from a 23339 function, but some class of functions only requires one 23340 instruction to implement a return. Normally, the applicable 23341 functions are those which do not need to save any registers or 23342 allocate stack space. 23343 23344 It is valid for this pattern to expand to an instruction using 23345 `simple_return' if no epilogue is required. 23346 23347`simple_return' 23348 Subroutine return instruction. This instruction pattern name 23349 should be defined only if a single instruction can do all the work 23350 of returning from a function on a path where no epilogue is 23351 required. This pattern is very similar to the `return' 23352 instruction pattern, but it is emitted only by the shrink-wrapping 23353 optimization on paths where the function prologue has not been 23354 executed, and a function return should occur without any of the 23355 effects of the epilogue. Additional uses may be introduced on 23356 paths where both the prologue and the epilogue have executed. 23357 23358 For such machines, the condition specified in this pattern should 23359 only be true when `reload_completed' is nonzero and the function's 23360 epilogue would only be a single instruction. For machines with 23361 register windows, the routine `leaf_function_p' may be used to 23362 determine if a register window push is required. 23363 23364 Machines that have conditional return instructions should define 23365 patterns such as 23366 23367 (define_insn "" 23368 [(set (pc) 23369 (if_then_else (match_operator 23370 0 "comparison_operator" 23371 [(cc0) (const_int 0)]) 23372 (return) 23373 (pc)))] 23374 "CONDITION" 23375 "...") 23376 23377 where CONDITION would normally be the same condition specified on 23378 the named `return' pattern. 23379 23380`untyped_return' 23381 Untyped subroutine return instruction. This instruction pattern 23382 should be defined to support `__builtin_return' on machines where 23383 special instructions are needed to return a value of any type. 23384 23385 Operand 0 is a memory location where the result of calling a 23386 function with `__builtin_apply' is stored; operand 1 is a 23387 `parallel' expression where each element is a `set' expression 23388 that indicates the restoring of a function return value from the 23389 result block. 23390 23391`nop' 23392 No-op instruction. This instruction pattern name should always be 23393 defined to output a no-op in assembler code. `(const_int 0)' will 23394 do as an RTL pattern. 23395 23396`indirect_jump' 23397 An instruction to jump to an address which is operand zero. This 23398 pattern name is mandatory on all machines. 23399 23400`casesi' 23401 Instruction to jump through a dispatch table, including bounds 23402 checking. This instruction takes five operands: 23403 23404 1. The index to dispatch on, which has mode `SImode'. 23405 23406 2. The lower bound for indices in the table, an integer constant. 23407 23408 3. The total range of indices in the table--the largest index 23409 minus the smallest one (both inclusive). 23410 23411 4. A label that precedes the table itself. 23412 23413 5. A label to jump to if the index has a value outside the 23414 bounds. 23415 23416 The table is an `addr_vec' or `addr_diff_vec' inside of a 23417 `jump_insn'. The number of elements in the table is one plus the 23418 difference between the upper bound and the lower bound. 23419 23420`tablejump' 23421 Instruction to jump to a variable address. This is a low-level 23422 capability which can be used to implement a dispatch table when 23423 there is no `casesi' pattern. 23424 23425 This pattern requires two operands: the address or offset, and a 23426 label which should immediately precede the jump table. If the 23427 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 23428 the first operand is an offset which counts from the address of 23429 the table; otherwise, it is an absolute address to jump to. In 23430 either case, the first operand has mode `Pmode'. 23431 23432 The `tablejump' insn is always the last insn before the jump table 23433 it uses. Its assembler code normally has no need to use the 23434 second operand, but you should incorporate it in the RTL pattern so 23435 that the jump optimizer will not delete the table as unreachable 23436 code. 23437 23438`decrement_and_branch_until_zero' 23439 Conditional branch instruction that decrements a register and 23440 jumps if the register is nonzero. Operand 0 is the register to 23441 decrement and test; operand 1 is the label to jump to if the 23442 register is nonzero. *Note Looping Patterns::. 23443 23444 This optional instruction pattern is only used by the combiner, 23445 typically for loops reversed by the loop optimizer when strength 23446 reduction is enabled. 23447 23448`doloop_end' 23449 Conditional branch instruction that decrements a register and 23450 jumps if the register is nonzero. This instruction takes five 23451 operands: Operand 0 is the register to decrement and test; operand 23452 1 is the number of loop iterations as a `const_int' or 23453 `const0_rtx' if this cannot be determined until run-time; operand 23454 2 is the actual or estimated maximum number of iterations as a 23455 `const_int'; operand 3 is the number of enclosed loops as a 23456 `const_int' (an innermost loop has a value of 1); operand 4 is the 23457 label to jump to if the register is nonzero; operand 5 is 23458 const1_rtx if the loop in entered at its top, const0_rtx otherwise. 23459 *Note Looping Patterns::. 23460 23461 This optional instruction pattern should be defined for machines 23462 with low-overhead looping instructions as the loop optimizer will 23463 try to modify suitable loops to utilize it. If nested 23464 low-overhead looping is not supported, use a `define_expand' 23465 (*note Expander Definitions::) and make the pattern fail if 23466 operand 3 is not `const1_rtx'. Similarly, if the actual or 23467 estimated maximum number of iterations is too large for this 23468 instruction, make it fail. 23469 23470`doloop_begin' 23471 Companion instruction to `doloop_end' required for machines that 23472 need to perform some initialization, such as loading special 23473 registers used by a low-overhead looping instruction. If 23474 initialization insns do not always need to be emitted, use a 23475 `define_expand' (*note Expander Definitions::) and make it fail. 23476 23477`canonicalize_funcptr_for_compare' 23478 Canonicalize the function pointer in operand 1 and store the result 23479 into operand 0. 23480 23481 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be 23482 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode 23483 `Pmode'. 23484 23485 Canonicalization of a function pointer usually involves computing 23486 the address of the function which would be called if the function 23487 pointer were used in an indirect call. 23488 23489 Only define this pattern if function pointers on the target machine 23490 can have different values but still call the same function when 23491 used in an indirect call. 23492 23493`save_stack_block' 23494`save_stack_function' 23495`save_stack_nonlocal' 23496`restore_stack_block' 23497`restore_stack_function' 23498`restore_stack_nonlocal' 23499 Most machines save and restore the stack pointer by copying it to 23500 or from an object of mode `Pmode'. Do not define these patterns on 23501 such machines. 23502 23503 Some machines require special handling for stack pointer saves and 23504 restores. On those machines, define the patterns corresponding to 23505 the non-standard cases by using a `define_expand' (*note Expander 23506 Definitions::) that produces the required insns. The three types 23507 of saves and restores are: 23508 23509 1. `save_stack_block' saves the stack pointer at the start of a 23510 block that allocates a variable-sized object, and 23511 `restore_stack_block' restores the stack pointer when the 23512 block is exited. 23513 23514 2. `save_stack_function' and `restore_stack_function' do a 23515 similar job for the outermost block of a function and are 23516 used when the function allocates variable-sized objects or 23517 calls `alloca'. Only the epilogue uses the restored stack 23518 pointer, allowing a simpler save or restore sequence on some 23519 machines. 23520 23521 3. `save_stack_nonlocal' is used in functions that contain labels 23522 branched to by nested functions. It saves the stack pointer 23523 in such a way that the inner function can use 23524 `restore_stack_nonlocal' to restore the stack pointer. The 23525 compiler generates code to restore the frame and argument 23526 pointer registers, but some machines require saving and 23527 restoring additional data such as register window information 23528 or stack backchains. Place insns in these patterns to save 23529 and restore any such required data. 23530 23531 When saving the stack pointer, operand 0 is the save area and 23532 operand 1 is the stack pointer. The mode used to allocate the 23533 save area defaults to `Pmode' but you can override that choice by 23534 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 23535 You must specify an integral mode, or `VOIDmode' if no save area 23536 is needed for a particular type of save (either because no save is 23537 needed or because a machine-specific save area can be used). 23538 Operand 0 is the stack pointer and operand 1 is the save area for 23539 restore operations. If `save_stack_block' is defined, operand 0 23540 must not be `VOIDmode' since these saves can be arbitrarily nested. 23541 23542 A save area is a `mem' that is at a constant offset from 23543 `virtual_stack_vars_rtx' when the stack pointer is saved for use by 23544 nonlocal gotos and a `reg' in the other two cases. 23545 23546`allocate_stack' 23547 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 23548 from the stack pointer to create space for dynamically allocated 23549 data. 23550 23551 Store the resultant pointer to this space into operand 0. If you 23552 are allocating space from the main stack, do this by emitting a 23553 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If 23554 you are allocating the space elsewhere, generate code to copy the 23555 location of the space to operand 0. In the latter case, you must 23556 ensure this space gets freed when the corresponding space on the 23557 main stack is free. 23558 23559 Do not define this pattern if all that must be done is the 23560 subtraction. Some machines require other operations such as stack 23561 probes or maintaining the back chain. Define this pattern to emit 23562 those operations in addition to updating the stack pointer. 23563 23564`check_stack' 23565 If stack checking (*note Stack Checking::) cannot be done on your 23566 system by probing the stack, define this pattern to perform the 23567 needed check and signal an error if the stack has overflowed. The 23568 single operand is the address in the stack farthest from the 23569 current stack pointer that you need to validate. Normally, on 23570 platforms where this pattern is needed, you would obtain the stack 23571 limit from a global or thread-specific variable or register. 23572 23573`probe_stack_address' 23574 If stack checking (*note Stack Checking::) can be done on your 23575 system by probing the stack but without the need to actually 23576 access it, define this pattern and signal an error if the stack 23577 has overflowed. The single operand is the memory address in the 23578 stack that needs to be probed. 23579 23580`probe_stack' 23581 If stack checking (*note Stack Checking::) can be done on your 23582 system by probing the stack but doing it with a "store zero" 23583 instruction is not valid or optimal, define this pattern to do the 23584 probing differently and signal an error if the stack has 23585 overflowed. The single operand is the memory reference in the 23586 stack that needs to be probed. 23587 23588`nonlocal_goto' 23589 Emit code to generate a non-local goto, e.g., a jump from one 23590 function to a label in an outer function. This pattern has four 23591 arguments, each representing a value to be used in the jump. The 23592 first argument is to be loaded into the frame pointer, the second 23593 is the address to branch to (code to dispatch to the actual label), 23594 the third is the address of a location where the stack is saved, 23595 and the last is the address of the label, to be placed in the 23596 location for the incoming static chain. 23597 23598 On most machines you need not define this pattern, since GCC will 23599 already generate the correct code, which is to load the frame 23600 pointer and static chain, restore the stack (using the 23601 `restore_stack_nonlocal' pattern, if defined), and jump indirectly 23602 to the dispatcher. You need only define this pattern if this code 23603 will not work on your machine. 23604 23605`nonlocal_goto_receiver' 23606 This pattern, if defined, contains code needed at the target of a 23607 nonlocal goto after the code already generated by GCC. You will 23608 not normally need to define this pattern. A typical reason why 23609 you might need this pattern is if some value, such as a pointer to 23610 a global table, must be restored when the frame pointer is 23611 restored. Note that a nonlocal goto only occurs within a 23612 unit-of-translation, so a global table pointer that is shared by 23613 all functions of a given module need not be restored. There are 23614 no arguments. 23615 23616`exception_receiver' 23617 This pattern, if defined, contains code needed at the site of an 23618 exception handler that isn't needed at the site of a nonlocal 23619 goto. You will not normally need to define this pattern. A 23620 typical reason why you might need this pattern is if some value, 23621 such as a pointer to a global table, must be restored after 23622 control flow is branched to the handler of an exception. There 23623 are no arguments. 23624 23625`builtin_setjmp_setup' 23626 This pattern, if defined, contains additional code needed to 23627 initialize the `jmp_buf'. You will not normally need to define 23628 this pattern. A typical reason why you might need this pattern is 23629 if some value, such as a pointer to a global table, must be 23630 restored. Though it is preferred that the pointer value be 23631 recalculated if possible (given the address of a label for 23632 instance). The single argument is a pointer to the `jmp_buf'. 23633 Note that the buffer is five words long and that the first three 23634 are normally used by the generic mechanism. 23635 23636`builtin_setjmp_receiver' 23637 This pattern, if defined, contains code needed at the site of a 23638 built-in setjmp that isn't needed at the site of a nonlocal goto. 23639 You will not normally need to define this pattern. A typical 23640 reason why you might need this pattern is if some value, such as a 23641 pointer to a global table, must be restored. It takes one 23642 argument, which is the label to which builtin_longjmp transferred 23643 control; this pattern may be emitted at a small offset from that 23644 label. 23645 23646`builtin_longjmp' 23647 This pattern, if defined, performs the entire action of the 23648 longjmp. You will not normally need to define this pattern unless 23649 you also define `builtin_setjmp_setup'. The single argument is a 23650 pointer to the `jmp_buf'. 23651 23652`eh_return' 23653 This pattern, if defined, affects the way `__builtin_eh_return', 23654 and thence the call frame exception handling library routines, are 23655 built. It is intended to handle non-trivial actions needed along 23656 the abnormal return path. 23657 23658 The address of the exception handler to which the function should 23659 return is passed as operand to this pattern. It will normally 23660 need to copied by the pattern to some special register or memory 23661 location. If the pattern needs to determine the location of the 23662 target call frame in order to do so, it may use 23663 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been 23664 assigned. 23665 23666 If this pattern is not defined, the default action will be to 23667 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either 23668 that macro or this pattern needs to be defined if call frame 23669 exception handling is to be used. 23670 23671`prologue' 23672 This pattern, if defined, emits RTL for entry to a function. The 23673 function entry is responsible for setting up the stack frame, 23674 initializing the frame pointer register, saving callee saved 23675 registers, etc. 23676 23677 Using a prologue pattern is generally preferred over defining 23678 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 23679 prologue. 23680 23681 The `prologue' pattern is particularly useful for targets which 23682 perform instruction scheduling. 23683 23684`window_save' 23685 This pattern, if defined, emits RTL for a register window save. 23686 It should be defined if the target machine has register windows 23687 but the window events are decoupled from calls to subroutines. 23688 The canonical example is the SPARC architecture. 23689 23690`epilogue' 23691 This pattern emits RTL for exit from a function. The function 23692 exit is responsible for deallocating the stack frame, restoring 23693 callee saved registers and emitting the return instruction. 23694 23695 Using an epilogue pattern is generally preferred over defining 23696 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 23697 epilogue. 23698 23699 The `epilogue' pattern is particularly useful for targets which 23700 perform instruction scheduling or which have delay slots for their 23701 return instruction. 23702 23703`sibcall_epilogue' 23704 This pattern, if defined, emits RTL for exit from a function 23705 without the final branch back to the calling function. This 23706 pattern will be emitted before any sibling call (aka tail call) 23707 sites. 23708 23709 The `sibcall_epilogue' pattern must not clobber any arguments used 23710 for parameter passing or any stack slots for arguments passed to 23711 the current function. 23712 23713`trap' 23714 This pattern, if defined, signals an error, typically by causing 23715 some kind of signal to be raised. Among other places, it is used 23716 by the Java front end to signal `invalid array index' exceptions. 23717 23718`ctrapMM4' 23719 Conditional trap instruction. Operand 0 is a piece of RTL which 23720 performs a comparison, and operands 1 and 2 are the arms of the 23721 comparison. Operand 3 is the trap code, an integer. 23722 23723 A typical `ctrap' pattern looks like 23724 23725 (define_insn "ctrapsi4" 23726 [(trap_if (match_operator 0 "trap_operator" 23727 [(match_operand 1 "register_operand") 23728 (match_operand 2 "immediate_operand")]) 23729 (match_operand 3 "const_int_operand" "i"))] 23730 "" 23731 "...") 23732 23733`prefetch' 23734 This pattern, if defined, emits code for a non-faulting data 23735 prefetch instruction. Operand 0 is the address of the memory to 23736 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 23737 for a write to the memory address, or a constant 0 otherwise. 23738 Operand 2 is the expected degree of temporal locality of the data 23739 and is a value between 0 and 3, inclusive; 0 means that the data 23740 has no temporal locality, so it need not be left in the cache 23741 after the access; 3 means that the data has a high degree of 23742 temporal locality and should be left in all levels of cache 23743 possible; 1 and 2 mean, respectively, a low or moderate degree of 23744 temporal locality. 23745 23746 Targets that do not support write prefetches or locality hints can 23747 ignore the values of operands 1 and 2. 23748 23749`blockage' 23750 This pattern defines a pseudo insn that prevents the instruction 23751 scheduler and other passes from moving instructions and using 23752 register equivalences across the boundary defined by the blockage 23753 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 23754 ASM. 23755 23756`memory_barrier' 23757 If the target memory model is not fully synchronous, then this 23758 pattern should be defined to an instruction that orders both loads 23759 and stores before the instruction with respect to loads and stores 23760 after the instruction. This pattern has no operands. 23761 23762`sync_compare_and_swapMODE' 23763 This pattern, if defined, emits code for an atomic compare-and-swap 23764 operation. Operand 1 is the memory on which the atomic operation 23765 is performed. Operand 2 is the "old" value to be compared against 23766 the current contents of the memory location. Operand 3 is the 23767 "new" value to store in the memory if the compare succeeds. 23768 Operand 0 is the result of the operation; it should contain the 23769 contents of the memory before the operation. If the compare 23770 succeeds, this should obviously be a copy of operand 2. 23771 23772 This pattern must show that both operand 0 and operand 1 are 23773 modified. 23774 23775 This pattern must issue any memory barrier instructions such that 23776 all memory operations before the atomic operation occur before the 23777 atomic operation and all memory operations after the atomic 23778 operation occur after the atomic operation. 23779 23780 For targets where the success or failure of the compare-and-swap 23781 operation is available via the status flags, it is possible to 23782 avoid a separate compare operation and issue the subsequent branch 23783 or store-flag operation immediately after the compare-and-swap. 23784 To this end, GCC will look for a `MODE_CC' set in the output of 23785 `sync_compare_and_swapMODE'; if the machine description includes 23786 such a set, the target should also define special `cbranchcc4' 23787 and/or `cstorecc4' instructions. GCC will then be able to take 23788 the destination of the `MODE_CC' set and pass it to the 23789 `cbranchcc4' or `cstorecc4' pattern as the first operand of the 23790 comparison (the second will be `(const_int 0)'). 23791 23792 For targets where the operating system may provide support for this 23793 operation via library calls, the `sync_compare_and_swap_optab' may 23794 be initialized to a function with the same interface as the 23795 `__sync_val_compare_and_swap_N' built-in. If the entire set of 23796 __SYNC builtins are supported via library calls, the target can 23797 initialize all of the optabs at once with `init_sync_libfuncs'. 23798 For the purposes of C++11 `std::atomic::is_lock_free', it is 23799 assumed that these library calls do _not_ use any kind of 23800 interruptable locking. 23801 23802`sync_addMODE', `sync_subMODE' 23803`sync_iorMODE', `sync_andMODE' 23804`sync_xorMODE', `sync_nandMODE' 23805 These patterns emit code for an atomic operation on memory. 23806 Operand 0 is the memory on which the atomic operation is performed. 23807 Operand 1 is the second operand to the binary operator. 23808 23809 This pattern must issue any memory barrier instructions such that 23810 all memory operations before the atomic operation occur before the 23811 atomic operation and all memory operations after the atomic 23812 operation occur after the atomic operation. 23813 23814 If these patterns are not defined, the operation will be 23815 constructed from a compare-and-swap operation, if defined. 23816 23817`sync_old_addMODE', `sync_old_subMODE' 23818`sync_old_iorMODE', `sync_old_andMODE' 23819`sync_old_xorMODE', `sync_old_nandMODE' 23820 These patterns emit code for an atomic operation on memory, and 23821 return the value that the memory contained before the operation. 23822 Operand 0 is the result value, operand 1 is the memory on which the 23823 atomic operation is performed, and operand 2 is the second operand 23824 to the binary operator. 23825 23826 This pattern must issue any memory barrier instructions such that 23827 all memory operations before the atomic operation occur before the 23828 atomic operation and all memory operations after the atomic 23829 operation occur after the atomic operation. 23830 23831 If these patterns are not defined, the operation will be 23832 constructed from a compare-and-swap operation, if defined. 23833 23834`sync_new_addMODE', `sync_new_subMODE' 23835`sync_new_iorMODE', `sync_new_andMODE' 23836`sync_new_xorMODE', `sync_new_nandMODE' 23837 These patterns are like their `sync_old_OP' counterparts, except 23838 that they return the value that exists in the memory location 23839 after the operation, rather than before the operation. 23840 23841`sync_lock_test_and_setMODE' 23842 This pattern takes two forms, based on the capabilities of the 23843 target. In either case, operand 0 is the result of the operand, 23844 operand 1 is the memory on which the atomic operation is 23845 performed, and operand 2 is the value to set in the lock. 23846 23847 In the ideal case, this operation is an atomic exchange operation, 23848 in which the previous value in memory operand is copied into the 23849 result operand, and the value operand is stored in the memory 23850 operand. 23851 23852 For less capable targets, any value operand that is not the 23853 constant 1 should be rejected with `FAIL'. In this case the 23854 target may use an atomic test-and-set bit operation. The result 23855 operand should contain 1 if the bit was previously set and 0 if 23856 the bit was previously clear. The true contents of the memory 23857 operand are implementation defined. 23858 23859 This pattern must issue any memory barrier instructions such that 23860 the pattern as a whole acts as an acquire barrier, that is all 23861 memory operations after the pattern do not occur until the lock is 23862 acquired. 23863 23864 If this pattern is not defined, the operation will be constructed 23865 from a compare-and-swap operation, if defined. 23866 23867`sync_lock_releaseMODE' 23868 This pattern, if defined, releases a lock set by 23869 `sync_lock_test_and_setMODE'. Operand 0 is the memory that 23870 contains the lock; operand 1 is the value to store in the lock. 23871 23872 If the target doesn't implement full semantics for 23873 `sync_lock_test_and_setMODE', any value operand which is not the 23874 constant 0 should be rejected with `FAIL', and the true contents 23875 of the memory operand are implementation defined. 23876 23877 This pattern must issue any memory barrier instructions such that 23878 the pattern as a whole acts as a release barrier, that is the lock 23879 is released only after all previous memory operations have 23880 completed. 23881 23882 If this pattern is not defined, then a `memory_barrier' pattern 23883 will be emitted, followed by a store of the value to the memory 23884 operand. 23885 23886`atomic_compare_and_swapMODE' 23887 This pattern, if defined, emits code for an atomic compare-and-swap 23888 operation with memory model semantics. Operand 2 is the memory on 23889 which the atomic operation is performed. Operand 0 is an output 23890 operand which is set to true or false based on whether the 23891 operation succeeded. Operand 1 is an output operand which is set 23892 to the contents of the memory before the operation was attempted. 23893 Operand 3 is the value that is expected to be in memory. Operand 23894 4 is the value to put in memory if the expected value is found 23895 there. Operand 5 is set to 1 if this compare and swap is to be 23896 treated as a weak operation. Operand 6 is the memory model to be 23897 used if the operation is a success. Operand 7 is the memory model 23898 to be used if the operation fails. 23899 23900 If memory referred to in operand 2 contains the value in operand 23901 3, then operand 4 is stored in memory pointed to by operand 2 and 23902 fencing based on the memory model in operand 6 is issued. 23903 23904 If memory referred to in operand 2 does not contain the value in 23905 operand 3, then fencing based on the memory model in operand 7 is 23906 issued. 23907 23908 If a target does not support weak compare-and-swap operations, or 23909 the port elects not to implement weak operations, the argument in 23910 operand 5 can be ignored. Note a strong implementation must be 23911 provided. 23912 23913 If this pattern is not provided, the `__atomic_compare_exchange' 23914 built-in functions will utilize the legacy `sync_compare_and_swap' 23915 pattern with an `__ATOMIC_SEQ_CST' memory model. 23916 23917`atomic_loadMODE' 23918 This pattern implements an atomic load operation with memory model 23919 semantics. Operand 1 is the memory address being loaded from. 23920 Operand 0 is the result of the load. Operand 2 is the memory 23921 model to be used for the load operation. 23922 23923 If not present, the `__atomic_load' built-in function will either 23924 resort to a normal load with memory barriers, or a compare-and-swap 23925 operation if a normal load would not be atomic. 23926 23927`atomic_storeMODE' 23928 This pattern implements an atomic store operation with memory model 23929 semantics. Operand 0 is the memory address being stored to. 23930 Operand 1 is the value to be written. Operand 2 is the memory 23931 model to be used for the operation. 23932 23933 If not present, the `__atomic_store' built-in function will 23934 attempt to perform a normal store and surround it with any 23935 required memory fences. If the store would not be atomic, then an 23936 `__atomic_exchange' is attempted with the result being ignored. 23937 23938`atomic_exchangeMODE' 23939 This pattern implements an atomic exchange operation with memory 23940 model semantics. Operand 1 is the memory location the operation 23941 is performed on. Operand 0 is an output operand which is set to 23942 the original value contained in the memory pointed to by operand 23943 1. Operand 2 is the value to be stored. Operand 3 is the memory 23944 model to be used. 23945 23946 If this pattern is not present, the built-in function 23947 `__atomic_exchange' will attempt to preform the operation with a 23948 compare and swap loop. 23949 23950`atomic_addMODE', `atomic_subMODE' 23951`atomic_orMODE', `atomic_andMODE' 23952`atomic_xorMODE', `atomic_nandMODE' 23953 These patterns emit code for an atomic operation on memory with 23954 memory model semantics. Operand 0 is the memory on which the 23955 atomic operation is performed. Operand 1 is the second operand to 23956 the binary operator. Operand 2 is the memory model to be used by 23957 the operation. 23958 23959 If these patterns are not defined, attempts will be made to use 23960 legacy `sync' patterns, or equivalent patterns which return a 23961 result. If none of these are available a compare-and-swap loop 23962 will be used. 23963 23964`atomic_fetch_addMODE', `atomic_fetch_subMODE' 23965`atomic_fetch_orMODE', `atomic_fetch_andMODE' 23966`atomic_fetch_xorMODE', `atomic_fetch_nandMODE' 23967 These patterns emit code for an atomic operation on memory with 23968 memory model semantics, and return the original value. Operand 0 23969 is an output operand which contains the value of the memory 23970 location before the operation was performed. Operand 1 is the 23971 memory on which the atomic operation is performed. Operand 2 is 23972 the second operand to the binary operator. Operand 3 is the 23973 memory model to be used by the operation. 23974 23975 If these patterns are not defined, attempts will be made to use 23976 legacy `sync' patterns. If none of these are available a 23977 compare-and-swap loop will be used. 23978 23979`atomic_add_fetchMODE', `atomic_sub_fetchMODE' 23980`atomic_or_fetchMODE', `atomic_and_fetchMODE' 23981`atomic_xor_fetchMODE', `atomic_nand_fetchMODE' 23982 These patterns emit code for an atomic operation on memory with 23983 memory model semantics and return the result after the operation 23984 is performed. Operand 0 is an output operand which contains the 23985 value after the operation. Operand 1 is the memory on which the 23986 atomic operation is performed. Operand 2 is the second operand to 23987 the binary operator. Operand 3 is the memory model to be used by 23988 the operation. 23989 23990 If these patterns are not defined, attempts will be made to use 23991 legacy `sync' patterns, or equivalent patterns which return the 23992 result before the operation followed by the arithmetic operation 23993 required to produce the result. If none of these are available a 23994 compare-and-swap loop will be used. 23995 23996`atomic_test_and_set' 23997 This pattern emits code for `__builtin_atomic_test_and_set'. 23998 Operand 0 is an output operand which is set to true if the previous 23999 previous contents of the byte was "set", and false otherwise. 24000 Operand 1 is the `QImode' memory to be modified. Operand 2 is the 24001 memory model to be used. 24002 24003 The specific value that defines "set" is implementation defined, 24004 and is normally based on what is performed by the native atomic 24005 test and set instruction. 24006 24007`mem_thread_fenceMODE' 24008 This pattern emits code required to implement a thread fence with 24009 memory model semantics. Operand 0 is the memory model to be used. 24010 24011 If this pattern is not specified, all memory models except 24012 `__ATOMIC_RELAXED' will result in issuing a `sync_synchronize' 24013 barrier pattern. 24014 24015`mem_signal_fenceMODE' 24016 This pattern emits code required to implement a signal fence with 24017 memory model semantics. Operand 0 is the memory model to be used. 24018 24019 This pattern should impact the compiler optimizers the same way 24020 that mem_signal_fence does, but it does not need to issue any 24021 barrier instructions. 24022 24023 If this pattern is not specified, all memory models except 24024 `__ATOMIC_RELAXED' will result in issuing a `sync_synchronize' 24025 barrier pattern. 24026 24027`get_thread_pointerMODE' 24028`set_thread_pointerMODE' 24029 These patterns emit code that reads/sets the TLS thread pointer. 24030 Currently, these are only needed if the target needs to support the 24031 `__builtin_thread_pointer' and `__builtin_set_thread_pointer' 24032 builtins. 24033 24034 The get/set patterns have a single output/input operand 24035 respectively, with MODE intended to be `Pmode'. 24036 24037`stack_protect_set' 24038 This pattern, if defined, moves a `ptr_mode' value from the memory 24039 in operand 1 to the memory in operand 0 without leaving the value 24040 in a register afterward. This is to avoid leaking the value some 24041 place that an attacker might use to rewrite the stack guard slot 24042 after having clobbered it. 24043 24044 If this pattern is not defined, then a plain move pattern is 24045 generated. 24046 24047`stack_protect_test' 24048 This pattern, if defined, compares a `ptr_mode' value from the 24049 memory in operand 1 with the memory in operand 0 without leaving 24050 the value in a register afterward and branches to operand 2 if the 24051 values were equal. 24052 24053 If this pattern is not defined, then a plain compare pattern and 24054 conditional branch pattern is used. 24055 24056`clear_cache' 24057 This pattern, if defined, flushes the instruction cache for a 24058 region of memory. The region is bounded to by the Pmode pointers 24059 in operand 0 inclusive and operand 1 exclusive. 24060 24061 If this pattern is not defined, a call to the library function 24062 `__clear_cache' is used. 24063 24064 24065 24066File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 24067 2406816.10 When the Order of Patterns Matters 24069======================================== 24070 24071Sometimes an insn can match more than one instruction pattern. Then the 24072pattern that appears first in the machine description is the one used. 24073Therefore, more specific patterns (patterns that will match fewer 24074things) and faster instructions (those that will produce better code 24075when they do match) should usually go first in the description. 24076 24077 In some cases the effect of ordering the patterns can be used to hide 24078a pattern when it is not valid. For example, the 68000 has an 24079instruction for converting a fullword to floating point and another for 24080converting a byte to floating point. An instruction converting an 24081integer to floating point could match either one. We put the pattern 24082to convert the fullword first to make sure that one will be used rather 24083than the other. (Otherwise a large integer might be generated as a 24084single-byte immediate quantity, which would not work.) Instead of 24085using this pattern ordering it would be possible to make the pattern 24086for convert-a-byte smart enough to deal properly with any constant 24087value. 24088 24089 24090File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 24091 2409216.11 Interdependence of Patterns 24093================================= 24094 24095In some cases machines support instructions identical except for the 24096machine mode of one or more operands. For example, there may be 24097"sign-extend halfword" and "sign-extend byte" instructions whose 24098patterns are 24099 24100 (set (match_operand:SI 0 ...) 24101 (extend:SI (match_operand:HI 1 ...))) 24102 24103 (set (match_operand:SI 0 ...) 24104 (extend:SI (match_operand:QI 1 ...))) 24105 24106Constant integers do not specify a machine mode, so an instruction to 24107extend a constant value could match either pattern. The pattern it 24108actually will match is the one that appears first in the file. For 24109correct results, this must be the one for the widest possible mode 24110(`HImode', here). If the pattern matches the `QImode' instruction, the 24111results will be incorrect if the constant value does not actually fit 24112that mode. 24113 24114 Such instructions to extend constants are rarely generated because 24115they are optimized away, but they do occasionally happen in nonoptimized 24116compilations. 24117 24118 If a constraint in a pattern allows a constant, the reload pass may 24119replace a register with a constant permitted by the constraint in some 24120cases. Similarly for memory references. Because of this substitution, 24121you should not provide separate patterns for increment and decrement 24122instructions. Instead, they should be generated from the same pattern 24123that supports register-register add insns by examining the operands and 24124generating the appropriate machine instruction. 24125 24126 24127File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 24128 2412916.12 Defining Jump Instruction Patterns 24130======================================== 24131 24132GCC does not assume anything about how the machine realizes jumps. The 24133machine description should define a single pattern, usually a 24134`define_expand', which expands to all the required insns. 24135 24136 Usually, this would be a comparison insn to set the condition code and 24137a separate branch insn testing the condition code and branching or not 24138according to its value. For many machines, however, separating 24139compares and branches is limiting, which is why the more flexible 24140approach with one `define_expand' is used in GCC. The machine 24141description becomes clearer for architectures that have 24142compare-and-branch instructions but no condition code. It also works 24143better when different sets of comparison operators are supported by 24144different kinds of conditional branches (e.g. integer vs. 24145floating-point), or by conditional branches with respect to conditional 24146stores. 24147 24148 Two separate insns are always used if the machine description 24149represents a condition code register using the legacy RTL expression 24150`(cc0)', and on most machines that use a separate condition code 24151register (*note Condition Code::). For machines that use `(cc0)', in 24152fact, the set and use of the condition code must be separate and 24153adjacent(1), thus allowing flags in `cc_status' to be used (*note 24154Condition Code::) and so that the comparison and branch insns could be 24155located from each other by using the functions `prev_cc0_setter' and 24156`next_cc0_user'. 24157 24158 Even in this case having a single entry point for conditional branches 24159is advantageous, because it handles equally well the case where a single 24160comparison instruction records the results of both signed and unsigned 24161comparison of the given operands (with the branch insns coming in 24162distinct signed and unsigned flavors) as in the x86 or SPARC, and the 24163case where there are distinct signed and unsigned compare instructions 24164and only one set of conditional branch instructions as in the PowerPC. 24165 24166 ---------- Footnotes ---------- 24167 24168 (1) `note' insns can separate them, though. 24169 24170 24171File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 24172 2417316.13 Defining Looping Instruction Patterns 24174=========================================== 24175 24176Some machines have special jump instructions that can be utilized to 24177make loops more efficient. A common example is the 68000 `dbra' 24178instruction which performs a decrement of a register and a branch if the 24179result was greater than zero. Other machines, in particular digital 24180signal processors (DSPs), have special block repeat instructions to 24181provide low-overhead loop support. For example, the TI TMS320C3x/C4x 24182DSPs have a block repeat instruction that loads special registers to 24183mark the top and end of a loop and to count the number of loop 24184iterations. This avoids the need for fetching and executing a 24185`dbra'-like instruction and avoids pipeline stalls associated with the 24186jump. 24187 24188 GCC has three special named patterns to support low overhead looping. 24189They are `decrement_and_branch_until_zero', `doloop_begin', and 24190`doloop_end'. The first pattern, `decrement_and_branch_until_zero', is 24191not emitted during RTL generation but may be emitted during the 24192instruction combination phase. This requires the assistance of the 24193loop optimizer, using information collected during strength reduction, 24194to reverse a loop to count down to zero. Some targets also require the 24195loop optimizer to add a `REG_NONNEG' note to indicate that the 24196iteration count is always positive. This is needed if the target 24197performs a signed loop termination test. For example, the 68000 uses a 24198pattern similar to the following for its `dbra' instruction: 24199 24200 (define_insn "decrement_and_branch_until_zero" 24201 [(set (pc) 24202 (if_then_else 24203 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 24204 (const_int -1)) 24205 (const_int 0)) 24206 (label_ref (match_operand 1 "" "")) 24207 (pc))) 24208 (set (match_dup 0) 24209 (plus:SI (match_dup 0) 24210 (const_int -1)))] 24211 "find_reg_note (insn, REG_NONNEG, 0)" 24212 "...") 24213 24214 Note that since the insn is both a jump insn and has an output, it must 24215deal with its own reloads, hence the `m' constraints. Also note that 24216since this insn is generated by the instruction combination phase 24217combining two sequential insns together into an implicit parallel insn, 24218the iteration counter needs to be biased by the same amount as the 24219decrement operation, in this case -1. Note that the following similar 24220pattern will not be matched by the combiner. 24221 24222 (define_insn "decrement_and_branch_until_zero" 24223 [(set (pc) 24224 (if_then_else 24225 (ge (match_operand:SI 0 "general_operand" "+d*am") 24226 (const_int 1)) 24227 (label_ref (match_operand 1 "" "")) 24228 (pc))) 24229 (set (match_dup 0) 24230 (plus:SI (match_dup 0) 24231 (const_int -1)))] 24232 "find_reg_note (insn, REG_NONNEG, 0)" 24233 "...") 24234 24235 The other two special looping patterns, `doloop_begin' and 24236`doloop_end', are emitted by the loop optimizer for certain 24237well-behaved loops with a finite number of loop iterations using 24238information collected during strength reduction. 24239 24240 The `doloop_end' pattern describes the actual looping instruction (or 24241the implicit looping operation) and the `doloop_begin' pattern is an 24242optional companion pattern that can be used for initialization needed 24243for some low-overhead looping instructions. 24244 24245 Note that some machines require the actual looping instruction to be 24246emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 24247the true RTL for a looping instruction at the top of the loop can cause 24248problems with flow analysis. So instead, a dummy `doloop' insn is 24249emitted at the end of the loop. The machine dependent reorg pass checks 24250for the presence of this `doloop' insn and then searches back to the 24251top of the loop, where it inserts the true looping insn (provided there 24252are no instructions in the loop which would cause problems). Any 24253additional labels can be emitted at this point. In addition, if the 24254desired special iteration counter register was not allocated, this 24255machine dependent reorg pass could emit a traditional compare and jump 24256instruction pair. 24257 24258 The essential difference between the `decrement_and_branch_until_zero' 24259and the `doloop_end' patterns is that the loop optimizer allocates an 24260additional pseudo register for the latter as an iteration counter. 24261This pseudo register cannot be used within the loop (i.e., general 24262induction variables cannot be derived from it), however, in many cases 24263the loop induction variable may become redundant and removed by the 24264flow pass. 24265 24266 24267File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 24268 2426916.14 Canonicalization of Instructions 24270====================================== 24271 24272There are often cases where multiple RTL expressions could represent an 24273operation performed by a single machine instruction. This situation is 24274most commonly encountered with logical, branch, and multiply-accumulate 24275instructions. In such cases, the compiler attempts to convert these 24276multiple RTL expressions into a single canonical form to reduce the 24277number of insn patterns required. 24278 24279 In addition to algebraic simplifications, following canonicalizations 24280are performed: 24281 24282 * For commutative and comparison operators, a constant is always 24283 made the second operand. If a machine only supports a constant as 24284 the second operand, only patterns that match a constant in the 24285 second operand need be supplied. 24286 24287 * For associative operators, a sequence of operators will always 24288 chain to the left; for instance, only the left operand of an 24289 integer `plus' can itself be a `plus'. `and', `ior', `xor', 24290 `plus', `mult', `smin', `smax', `umin', and `umax' are associative 24291 when applied to integers, and sometimes to floating-point. 24292 24293 * For these operators, if only one operand is a `neg', `not', 24294 `mult', `plus', or `minus' expression, it will be the first 24295 operand. 24296 24297 * In combinations of `neg', `mult', `plus', and `minus', the `neg' 24298 operations (if any) will be moved inside the operations as far as 24299 possible. For instance, `(neg (mult A B))' is canonicalized as 24300 `(mult (neg A) B)', but `(plus (mult (neg B) C) A)' is 24301 canonicalized as `(minus A (mult B C))'. 24302 24303 * For the `compare' operator, a constant is always the second operand 24304 if the first argument is a condition code register or `(cc0)'. 24305 24306 * An operand of `neg', `not', `mult', `plus', or `minus' is made the 24307 first operand under the same conditions as above. 24308 24309 * `(ltu (plus A B) B)' is converted to `(ltu (plus A B) A)'. 24310 Likewise with `geu' instead of `ltu'. 24311 24312 * `(minus X (const_int N))' is converted to `(plus X (const_int 24313 -N))'. 24314 24315 * Within address computations (i.e., inside `mem'), a left shift is 24316 converted into the appropriate multiplication by a power of two. 24317 24318 * De Morgan's Law is used to move bitwise negation inside a bitwise 24319 logical-and or logical-or operation. If this results in only one 24320 operand being a `not' expression, it will be the first one. 24321 24322 A machine that has an instruction that performs a bitwise 24323 logical-and of one operand with the bitwise negation of the other 24324 should specify the pattern for that instruction as 24325 24326 (define_insn "" 24327 [(set (match_operand:M 0 ...) 24328 (and:M (not:M (match_operand:M 1 ...)) 24329 (match_operand:M 2 ...)))] 24330 "..." 24331 "...") 24332 24333 Similarly, a pattern for a "NAND" instruction should be written 24334 24335 (define_insn "" 24336 [(set (match_operand:M 0 ...) 24337 (ior:M (not:M (match_operand:M 1 ...)) 24338 (not:M (match_operand:M 2 ...))))] 24339 "..." 24340 "...") 24341 24342 In both cases, it is not necessary to include patterns for the many 24343 logically equivalent RTL expressions. 24344 24345 * The only possible RTL expressions involving both bitwise 24346 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M 24347 (xor:M X Y))'. 24348 24349 * The sum of three items, one of which is a constant, will only 24350 appear in the form 24351 24352 (plus:M (plus:M X Y) CONSTANT) 24353 24354 * Equality comparisons of a group of bits (usually a single bit) 24355 with zero will be written using `zero_extract' rather than the 24356 equivalent `and' or `sign_extract' operations. 24357 24358 * `(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 24359 is converted to `(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 24360 and likewise for `zero_extend'. 24361 24362 * `(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 24363 is converted to `(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 24364 (sign_extend:M1 Y))', and likewise for patterns using 24365 `zero_extend' and `lshiftrt'. If the second operand of `mult' is 24366 also a shift, then that is extended also. This transformation is 24367 only applied when it can be proven that the original operation had 24368 sufficient precision to prevent overflow. 24369 24370 24371 Further canonicalization rules are defined in the function 24372`commutative_operand_precedence' in `gcc/rtlanal.c'. 24373 24374 24375File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 24376 2437716.15 Defining RTL Sequences for Code Generation 24378================================================ 24379 24380On some target machines, some standard pattern names for RTL generation 24381cannot be handled with single insn, but a sequence of RTL insns can 24382represent them. For these target machines, you can write a 24383`define_expand' to specify how to generate the sequence of RTL. 24384 24385 A `define_expand' is an RTL expression that looks almost like a 24386`define_insn'; but, unlike the latter, a `define_expand' is used only 24387for RTL generation and it can produce more than one RTL insn. 24388 24389 A `define_expand' RTX has four operands: 24390 24391 * The name. Each `define_expand' must have a name, since the only 24392 use for it is to refer to it by name. 24393 24394 * The RTL template. This is a vector of RTL expressions representing 24395 a sequence of separate instructions. Unlike `define_insn', there 24396 is no implicit surrounding `PARALLEL'. 24397 24398 * The condition, a string containing a C expression. This 24399 expression is used to express how the availability of this pattern 24400 depends on subclasses of target machine, selected by command-line 24401 options when GCC is run. This is just like the condition of a 24402 `define_insn' that has a standard name. Therefore, the condition 24403 (if present) may not depend on the data in the insn being matched, 24404 but only the target-machine-type flags. The compiler needs to 24405 test these conditions during initialization in order to learn 24406 exactly which named instructions are available in a particular run. 24407 24408 * The preparation statements, a string containing zero or more C 24409 statements which are to be executed before RTL code is generated 24410 from the RTL template. 24411 24412 Usually these statements prepare temporary registers for use as 24413 internal operands in the RTL template, but they can also generate 24414 RTL insns directly by calling routines such as `emit_insn', etc. 24415 Any such insns precede the ones that come from the RTL template. 24416 24417 * Optionally, a vector containing the values of attributes. *Note 24418 Insn Attributes::. 24419 24420 Every RTL insn emitted by a `define_expand' must match some 24421`define_insn' in the machine description. Otherwise, the compiler will 24422crash when trying to generate code for the insn or trying to optimize 24423it. 24424 24425 The RTL template, in addition to controlling generation of RTL insns, 24426also describes the operands that need to be specified when this pattern 24427is used. In particular, it gives a predicate for each operand. 24428 24429 A true operand, which needs to be specified in order to generate RTL 24430from the pattern, should be described with a `match_operand' in its 24431first occurrence in the RTL template. This enters information on the 24432operand's predicate into the tables that record such things. GCC uses 24433the information to preload the operand into a register if that is 24434required for valid RTL code. If the operand is referred to more than 24435once, subsequent references should use `match_dup'. 24436 24437 The RTL template may also refer to internal "operands" which are 24438temporary registers or labels used only within the sequence made by the 24439`define_expand'. Internal operands are substituted into the RTL 24440template with `match_dup', never with `match_operand'. The values of 24441the internal operands are not passed in as arguments by the compiler 24442when it requests use of this pattern. Instead, they are computed 24443within the pattern, in the preparation statements. These statements 24444compute the values and store them into the appropriate elements of 24445`operands' so that `match_dup' can find them. 24446 24447 There are two special macros defined for use in the preparation 24448statements: `DONE' and `FAIL'. Use them with a following semicolon, as 24449a statement. 24450 24451`DONE' 24452 Use the `DONE' macro to end RTL generation for the pattern. The 24453 only RTL insns resulting from the pattern on this occasion will be 24454 those already emitted by explicit calls to `emit_insn' within the 24455 preparation statements; the RTL template will not be generated. 24456 24457`FAIL' 24458 Make the pattern fail on this occasion. When a pattern fails, it 24459 means that the pattern was not truly available. The calling 24460 routines in the compiler will try other strategies for code 24461 generation using other patterns. 24462 24463 Failure is currently supported only for binary (addition, 24464 multiplication, shifting, etc.) and bit-field (`extv', `extzv', 24465 and `insv') operations. 24466 24467 If the preparation falls through (invokes neither `DONE' nor `FAIL'), 24468then the `define_expand' acts like a `define_insn' in that the RTL 24469template is used to generate the insn. 24470 24471 The RTL template is not used for matching, only for generating the 24472initial insn list. If the preparation statement always invokes `DONE' 24473or `FAIL', the RTL template may be reduced to a simple list of 24474operands, such as this example: 24475 24476 (define_expand "addsi3" 24477 [(match_operand:SI 0 "register_operand" "") 24478 (match_operand:SI 1 "register_operand" "") 24479 (match_operand:SI 2 "register_operand" "")] 24480 "" 24481 " 24482 { 24483 handle_add (operands[0], operands[1], operands[2]); 24484 DONE; 24485 }") 24486 24487 Here is an example, the definition of left-shift for the SPUR chip: 24488 24489 (define_expand "ashlsi3" 24490 [(set (match_operand:SI 0 "register_operand" "") 24491 (ashift:SI 24492 (match_operand:SI 1 "register_operand" "") 24493 (match_operand:SI 2 "nonmemory_operand" "")))] 24494 "" 24495 " 24496 24497 { 24498 if (GET_CODE (operands[2]) != CONST_INT 24499 || (unsigned) INTVAL (operands[2]) > 3) 24500 FAIL; 24501 }") 24502 24503This example uses `define_expand' so that it can generate an RTL insn 24504for shifting when the shift-count is in the supported range of 0 to 3 24505but fail in other cases where machine insns aren't available. When it 24506fails, the compiler tries another strategy using different patterns 24507(such as, a library call). 24508 24509 If the compiler were able to handle nontrivial condition-strings in 24510patterns with names, then it would be possible to use a `define_insn' 24511in that case. Here is another case (zero-extension on the 68000) which 24512makes more use of the power of `define_expand': 24513 24514 (define_expand "zero_extendhisi2" 24515 [(set (match_operand:SI 0 "general_operand" "") 24516 (const_int 0)) 24517 (set (strict_low_part 24518 (subreg:HI 24519 (match_dup 0) 24520 0)) 24521 (match_operand:HI 1 "general_operand" ""))] 24522 "" 24523 "operands[1] = make_safe_from (operands[1], operands[0]);") 24524 24525Here two RTL insns are generated, one to clear the entire output operand 24526and the other to copy the input operand into its low half. This 24527sequence is incorrect if the input operand refers to [the old value of] 24528the output operand, so the preparation statement makes sure this isn't 24529so. The function `make_safe_from' copies the `operands[1]' into a 24530temporary register if it refers to `operands[0]'. It does this by 24531emitting another RTL insn. 24532 24533 Finally, a third example shows the use of an internal operand. 24534Zero-extension on the SPUR chip is done by `and'-ing the result against 24535a halfword mask. But this mask cannot be represented by a `const_int' 24536because the constant value is too large to be legitimate on this 24537machine. So it must be copied into a register with `force_reg' and 24538then the register used in the `and'. 24539 24540 (define_expand "zero_extendhisi2" 24541 [(set (match_operand:SI 0 "register_operand" "") 24542 (and:SI (subreg:SI 24543 (match_operand:HI 1 "register_operand" "") 24544 0) 24545 (match_dup 2)))] 24546 "" 24547 "operands[2] 24548 = force_reg (SImode, GEN_INT (65535)); ") 24549 24550 _Note:_ If the `define_expand' is used to serve a standard binary or 24551unary arithmetic operation or a bit-field operation, then the last insn 24552it generates must not be a `code_label', `barrier' or `note'. It must 24553be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 24554at the end, emit an insn to copy the result of the operation into 24555itself. Such an insn will generate no code, but it can avoid problems 24556in the compiler. 24557 24558 24559File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 24560 2456116.16 Defining How to Split Instructions 24562======================================== 24563 24564There are two cases where you should specify how to split a pattern 24565into multiple insns. On machines that have instructions requiring 24566delay slots (*note Delay Slots::) or that have instructions whose 24567output is not available for multiple cycles (*note Processor pipeline 24568description::), the compiler phases that optimize these cases need to 24569be able to move insns into one-instruction delay slots. However, some 24570insns may generate more than one machine instruction. These insns 24571cannot be placed into a delay slot. 24572 24573 Often you can rewrite the single insn as a list of individual insns, 24574each corresponding to one machine instruction. The disadvantage of 24575doing so is that it will cause the compilation to be slower and require 24576more space. If the resulting insns are too complex, it may also 24577suppress some optimizations. The compiler splits the insn if there is a 24578reason to believe that it might improve instruction or delay slot 24579scheduling. 24580 24581 The insn combiner phase also splits putative insns. If three insns are 24582merged into one insn with a complex expression that cannot be matched by 24583some `define_insn' pattern, the combiner phase attempts to split the 24584complex pattern into two insns that are recognized. Usually it can 24585break the complex pattern into two patterns by splitting out some 24586subexpression. However, in some other cases, such as performing an 24587addition of a large constant in two insns on a RISC machine, the way to 24588split the addition into two insns is machine-dependent. 24589 24590 The `define_split' definition tells the compiler how to split a 24591complex insn into several simpler insns. It looks like this: 24592 24593 (define_split 24594 [INSN-PATTERN] 24595 "CONDITION" 24596 [NEW-INSN-PATTERN-1 24597 NEW-INSN-PATTERN-2 24598 ...] 24599 "PREPARATION-STATEMENTS") 24600 24601 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 24602final condition to be tested, as in a `define_insn'. When an insn 24603matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 24604in the insn list with the insns given by NEW-INSN-PATTERN-1, 24605NEW-INSN-PATTERN-2, etc. 24606 24607 The PREPARATION-STATEMENTS are similar to those statements that are 24608specified for `define_expand' (*note Expander Definitions::) and are 24609executed before the new RTL is generated to prepare for the generated 24610code or emit some insns whose pattern is not fixed. Unlike those in 24611`define_expand', however, these statements must not generate any new 24612pseudo-registers. Once reload has completed, they also must not 24613allocate any space in the stack frame. 24614 24615 Patterns are matched against INSN-PATTERN in two different 24616circumstances. If an insn needs to be split for delay slot scheduling 24617or insn scheduling, the insn is already known to be valid, which means 24618that it must have been matched by some `define_insn' and, if 24619`reload_completed' is nonzero, is known to satisfy the constraints of 24620that `define_insn'. In that case, the new insn patterns must also be 24621insns that are matched by some `define_insn' and, if `reload_completed' 24622is nonzero, must also satisfy the constraints of those definitions. 24623 24624 As an example of this usage of `define_split', consider the following 24625example from `a29k.md', which splits a `sign_extend' from `HImode' to 24626`SImode' into a pair of shift insns: 24627 24628 (define_split 24629 [(set (match_operand:SI 0 "gen_reg_operand" "") 24630 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 24631 "" 24632 [(set (match_dup 0) 24633 (ashift:SI (match_dup 1) 24634 (const_int 16))) 24635 (set (match_dup 0) 24636 (ashiftrt:SI (match_dup 0) 24637 (const_int 16)))] 24638 " 24639 { operands[1] = gen_lowpart (SImode, operands[1]); }") 24640 24641 When the combiner phase tries to split an insn pattern, it is always 24642the case that the pattern is _not_ matched by any `define_insn'. The 24643combiner pass first tries to split a single `set' expression and then 24644the same `set' expression inside a `parallel', but followed by a 24645`clobber' of a pseudo-reg to use as a scratch register. In these 24646cases, the combiner expects exactly two new insn patterns to be 24647generated. It will verify that these patterns match some `define_insn' 24648definitions, so you need not do this test in the `define_split' (of 24649course, there is no point in writing a `define_split' that will never 24650produce insns that match). 24651 24652 Here is an example of this use of `define_split', taken from 24653`rs6000.md': 24654 24655 (define_split 24656 [(set (match_operand:SI 0 "gen_reg_operand" "") 24657 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 24658 (match_operand:SI 2 "non_add_cint_operand" "")))] 24659 "" 24660 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 24661 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 24662 " 24663 { 24664 int low = INTVAL (operands[2]) & 0xffff; 24665 int high = (unsigned) INTVAL (operands[2]) >> 16; 24666 24667 if (low & 0x8000) 24668 high++, low |= 0xffff0000; 24669 24670 operands[3] = GEN_INT (high << 16); 24671 operands[4] = GEN_INT (low); 24672 }") 24673 24674 Here the predicate `non_add_cint_operand' matches any `const_int' that 24675is _not_ a valid operand of a single add insn. The add with the 24676smaller displacement is written so that it can be substituted into the 24677address of a subsequent operation. 24678 24679 An example that uses a scratch register, from the same file, generates 24680an equality comparison of a register and a large constant: 24681 24682 (define_split 24683 [(set (match_operand:CC 0 "cc_reg_operand" "") 24684 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 24685 (match_operand:SI 2 "non_short_cint_operand" ""))) 24686 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 24687 "find_single_use (operands[0], insn, 0) 24688 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 24689 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 24690 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 24691 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 24692 " 24693 { 24694 /* Get the constant we are comparing against, C, and see what it 24695 looks like sign-extended to 16 bits. Then see what constant 24696 could be XOR'ed with C to get the sign-extended value. */ 24697 24698 int c = INTVAL (operands[2]); 24699 int sextc = (c << 16) >> 16; 24700 int xorv = c ^ sextc; 24701 24702 operands[4] = GEN_INT (xorv); 24703 operands[5] = GEN_INT (sextc); 24704 }") 24705 24706 To avoid confusion, don't write a single `define_split' that accepts 24707some insns that match some `define_insn' as well as some insns that 24708don't. Instead, write two separate `define_split' definitions, one for 24709the insns that are valid and one for the insns that are not valid. 24710 24711 The splitter is allowed to split jump instructions into sequence of 24712jumps or create new jumps in while splitting non-jump instructions. As 24713the central flowgraph and branch prediction information needs to be 24714updated, several restriction apply. 24715 24716 Splitting of jump instruction into sequence that over by another jump 24717instruction is always valid, as compiler expect identical behavior of 24718new jump. When new sequence contains multiple jump instructions or new 24719labels, more assistance is needed. Splitter is required to create only 24720unconditional jumps, or simple conditional jump instructions. 24721Additionally it must attach a `REG_BR_PROB' note to each conditional 24722jump. A global variable `split_branch_probability' holds the 24723probability of the original branch in case it was a simple conditional 24724jump, -1 otherwise. To simplify recomputing of edge frequencies, the 24725new sequence is required to have only forward jumps to the newly 24726created labels. 24727 24728 For the common case where the pattern of a define_split exactly 24729matches the pattern of a define_insn, use `define_insn_and_split'. It 24730looks like this: 24731 24732 (define_insn_and_split 24733 [INSN-PATTERN] 24734 "CONDITION" 24735 "OUTPUT-TEMPLATE" 24736 "SPLIT-CONDITION" 24737 [NEW-INSN-PATTERN-1 24738 NEW-INSN-PATTERN-2 24739 ...] 24740 "PREPARATION-STATEMENTS" 24741 [INSN-ATTRIBUTES]) 24742 24743 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 24744as in `define_insn'. The NEW-INSN-PATTERN vector and the 24745PREPARATION-STATEMENTS are used as in a `define_split'. The 24746SPLIT-CONDITION is also used as in `define_split', with the additional 24747behavior that if the condition starts with `&&', the condition used for 24748the split will be the constructed as a logical "and" of the split 24749condition with the insn condition. For example, from i386.md: 24750 24751 (define_insn_and_split "zero_extendhisi2_and" 24752 [(set (match_operand:SI 0 "register_operand" "=r") 24753 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 24754 (clobber (reg:CC 17))] 24755 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 24756 "#" 24757 "&& reload_completed" 24758 [(parallel [(set (match_dup 0) 24759 (and:SI (match_dup 0) (const_int 65535))) 24760 (clobber (reg:CC 17))])] 24761 "" 24762 [(set_attr "type" "alu1")]) 24763 24764 In this case, the actual split condition will be 24765`TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 24766 24767 The `define_insn_and_split' construction provides exactly the same 24768functionality as two separate `define_insn' and `define_split' 24769patterns. It exists for compactness, and as a maintenance tool to 24770prevent having to ensure the two patterns' templates match. 24771 24772 24773File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 24774 2477516.17 Including Patterns in Machine Descriptions. 24776================================================= 24777 24778The `include' pattern tells the compiler tools where to look for 24779patterns that are in files other than in the file `.md'. This is used 24780only at build time and there is no preprocessing allowed. 24781 24782 It looks like: 24783 24784 24785 (include 24786 PATHNAME) 24787 24788 For example: 24789 24790 24791 (include "filestuff") 24792 24793 Where PATHNAME is a string that specifies the location of the file, 24794specifies the include file to be in `gcc/config/target/filestuff'. The 24795directory `gcc/config/target' is regarded as the default directory. 24796 24797 Machine descriptions may be split up into smaller more manageable 24798subsections and placed into subdirectories. 24799 24800 By specifying: 24801 24802 24803 (include "BOGUS/filestuff") 24804 24805 the include file is specified to be in 24806`gcc/config/TARGET/BOGUS/filestuff'. 24807 24808 Specifying an absolute path for the include file such as; 24809 24810 (include "/u2/BOGUS/filestuff") 24811 is permitted but is not encouraged. 24812 2481316.17.1 RTL Generation Tool Options for Directory Search 24814-------------------------------------------------------- 24815 24816The `-IDIR' option specifies directories to search for machine 24817descriptions. For example: 24818 24819 24820 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 24821 24822 Add the directory DIR to the head of the list of directories to be 24823searched for header files. This can be used to override a system 24824machine definition file, substituting your own version, since these 24825directories are searched before the default machine description file 24826directories. If you use more than one `-I' option, the directories are 24827scanned in left-to-right order; the standard default directory come 24828after. 24829 24830 24831File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 24832 2483316.18 Machine-Specific Peephole Optimizers 24834========================================== 24835 24836In addition to instruction patterns the `md' file may contain 24837definitions of machine-specific peephole optimizations. 24838 24839 The combiner does not notice certain peephole optimizations when the 24840data flow in the program does not suggest that it should try them. For 24841example, sometimes two consecutive insns related in purpose can be 24842combined even though the second one does not appear to use a register 24843computed in the first one. A machine-specific peephole optimizer can 24844detect such opportunities. 24845 24846 There are two forms of peephole definitions that may be used. The 24847original `define_peephole' is run at assembly output time to match 24848insns and substitute assembly text. Use of `define_peephole' is 24849deprecated. 24850 24851 A newer `define_peephole2' matches insns and substitutes new insns. 24852The `peephole2' pass is run after register allocation but before 24853scheduling, which may result in much better code for targets that do 24854scheduling. 24855 24856* Menu: 24857 24858* define_peephole:: RTL to Text Peephole Optimizers 24859* define_peephole2:: RTL to RTL Peephole Optimizers 24860 24861 24862File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 24863 2486416.18.1 RTL to Text Peephole Optimizers 24865--------------------------------------- 24866 24867A definition looks like this: 24868 24869 (define_peephole 24870 [INSN-PATTERN-1 24871 INSN-PATTERN-2 24872 ...] 24873 "CONDITION" 24874 "TEMPLATE" 24875 "OPTIONAL-INSN-ATTRIBUTES") 24876 24877The last string operand may be omitted if you are not using any 24878machine-specific information in this machine description. If present, 24879it must obey the same rules as in a `define_insn'. 24880 24881 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 24882consecutive insns. The optimization applies to a sequence of insns when 24883INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 24884and so on. 24885 24886 Each of the insns matched by a peephole must also match a 24887`define_insn'. Peepholes are checked only at the last stage just 24888before code generation, and only optionally. Therefore, any insn which 24889would match a peephole but no `define_insn' will cause a crash in code 24890generation in an unoptimized compilation, or at various optimization 24891stages. 24892 24893 The operands of the insns are matched with `match_operands', 24894`match_operator', and `match_dup', as usual. What is not usual is that 24895the operand numbers apply to all the insn patterns in the definition. 24896So, you can check for identical operands in two insns by using 24897`match_operand' in one insn and `match_dup' in the other. 24898 24899 The operand constraints used in `match_operand' patterns do not have 24900any direct effect on the applicability of the peephole, but they will 24901be validated afterward, so make sure your constraints are general enough 24902to apply whenever the peephole matches. If the peephole matches but 24903the constraints are not satisfied, the compiler will crash. 24904 24905 It is safe to omit constraints in all the operands of the peephole; or 24906you can write constraints which serve as a double-check on the criteria 24907previously tested. 24908 24909 Once a sequence of insns matches the patterns, the CONDITION is 24910checked. This is a C expression which makes the final decision whether 24911to perform the optimization (we do so if the expression is nonzero). If 24912CONDITION is omitted (in other words, the string is empty) then the 24913optimization is applied to every sequence of insns that matches the 24914patterns. 24915 24916 The defined peephole optimizations are applied after register 24917allocation is complete. Therefore, the peephole definition can check 24918which operands have ended up in which kinds of registers, just by 24919looking at the operands. 24920 24921 The way to refer to the operands in CONDITION is to write 24922`operands[I]' for operand number I (as matched by `(match_operand I 24923...)'). Use the variable `insn' to refer to the last of the insns 24924being matched; use `prev_active_insn' to find the preceding insns. 24925 24926 When optimizing computations with intermediate results, you can use 24927CONDITION to match only when the intermediate results are not used 24928elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN 24929is the insn in which you expect the value to be used for the last time 24930(from the value of `insn', together with use of `prev_nonnote_insn'), 24931and OP is the intermediate value (from `operands[I]'). 24932 24933 Applying the optimization means replacing the sequence of insns with 24934one new insn. The TEMPLATE controls ultimate output of assembler code 24935for this combined insn. It works exactly like the template of a 24936`define_insn'. Operand numbers in this template are the same ones used 24937in matching the original sequence of insns. 24938 24939 The result of a defined peephole optimizer does not need to match any 24940of the insn patterns in the machine description; it does not even have 24941an opportunity to match them. The peephole optimizer definition itself 24942serves as the insn pattern to control how the insn is output. 24943 24944 Defined peephole optimizers are run as assembler code is being output, 24945so the insns they produce are never combined or rearranged in any way. 24946 24947 Here is an example, taken from the 68000 machine description: 24948 24949 (define_peephole 24950 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 24951 (set (match_operand:DF 0 "register_operand" "=f") 24952 (match_operand:DF 1 "register_operand" "ad"))] 24953 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 24954 { 24955 rtx xoperands[2]; 24956 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 24957 #ifdef MOTOROLA 24958 output_asm_insn ("move.l %1,(sp)", xoperands); 24959 output_asm_insn ("move.l %1,-(sp)", operands); 24960 return "fmove.d (sp)+,%0"; 24961 #else 24962 output_asm_insn ("movel %1,sp@", xoperands); 24963 output_asm_insn ("movel %1,sp@-", operands); 24964 return "fmoved sp@+,%0"; 24965 #endif 24966 }) 24967 24968 The effect of this optimization is to change 24969 24970 jbsr _foobar 24971 addql #4,sp 24972 movel d1,sp@- 24973 movel d0,sp@- 24974 fmoved sp@+,fp0 24975 24976into 24977 24978 jbsr _foobar 24979 movel d1,sp@ 24980 movel d0,sp@- 24981 fmoved sp@+,fp0 24982 24983 INSN-PATTERN-1 and so on look _almost_ like the second operand of 24984`define_insn'. There is one important difference: the second operand 24985of `define_insn' consists of one or more RTX's enclosed in square 24986brackets. Usually, there is only one: then the same action can be 24987written as an element of a `define_peephole'. But when there are 24988multiple actions in a `define_insn', they are implicitly enclosed in a 24989`parallel'. Then you must explicitly write the `parallel', and the 24990square brackets within it, in the `define_peephole'. Thus, if an insn 24991pattern looks like this, 24992 24993 (define_insn "divmodsi4" 24994 [(set (match_operand:SI 0 "general_operand" "=d") 24995 (div:SI (match_operand:SI 1 "general_operand" "0") 24996 (match_operand:SI 2 "general_operand" "dmsK"))) 24997 (set (match_operand:SI 3 "general_operand" "=d") 24998 (mod:SI (match_dup 1) (match_dup 2)))] 24999 "TARGET_68020" 25000 "divsl%.l %2,%3:%0") 25001 25002then the way to mention this insn in a peephole is as follows: 25003 25004 (define_peephole 25005 [... 25006 (parallel 25007 [(set (match_operand:SI 0 "general_operand" "=d") 25008 (div:SI (match_operand:SI 1 "general_operand" "0") 25009 (match_operand:SI 2 "general_operand" "dmsK"))) 25010 (set (match_operand:SI 3 "general_operand" "=d") 25011 (mod:SI (match_dup 1) (match_dup 2)))]) 25012 ...] 25013 ...) 25014 25015 25016File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 25017 2501816.18.2 RTL to RTL Peephole Optimizers 25019-------------------------------------- 25020 25021The `define_peephole2' definition tells the compiler how to substitute 25022one sequence of instructions for another sequence, what additional 25023scratch registers may be needed and what their lifetimes must be. 25024 25025 (define_peephole2 25026 [INSN-PATTERN-1 25027 INSN-PATTERN-2 25028 ...] 25029 "CONDITION" 25030 [NEW-INSN-PATTERN-1 25031 NEW-INSN-PATTERN-2 25032 ...] 25033 "PREPARATION-STATEMENTS") 25034 25035 The definition is almost identical to `define_split' (*note Insn 25036Splitting::) except that the pattern to match is not a single 25037instruction, but a sequence of instructions. 25038 25039 It is possible to request additional scratch registers for use in the 25040output template. If appropriate registers are not free, the pattern 25041will simply not match. 25042 25043 Scratch registers are requested with a `match_scratch' pattern at the 25044top level of the input pattern. The allocated register (initially) will 25045be dead at the point requested within the original sequence. If the 25046scratch is used at more than a single point, a `match_dup' pattern at 25047the top level of the input pattern marks the last position in the input 25048sequence at which the register must be available. 25049 25050 Here is an example from the IA-32 machine description: 25051 25052 (define_peephole2 25053 [(match_scratch:SI 2 "r") 25054 (parallel [(set (match_operand:SI 0 "register_operand" "") 25055 (match_operator:SI 3 "arith_or_logical_operator" 25056 [(match_dup 0) 25057 (match_operand:SI 1 "memory_operand" "")])) 25058 (clobber (reg:CC 17))])] 25059 "! optimize_size && ! TARGET_READ_MODIFY" 25060 [(set (match_dup 2) (match_dup 1)) 25061 (parallel [(set (match_dup 0) 25062 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 25063 (clobber (reg:CC 17))])] 25064 "") 25065 25066This pattern tries to split a load from its use in the hopes that we'll 25067be able to schedule around the memory load latency. It allocates a 25068single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to 25069be live only at the point just before the arithmetic. 25070 25071 A real example requiring extended scratch lifetimes is harder to come 25072by, so here's a silly made-up example: 25073 25074 (define_peephole2 25075 [(match_scratch:SI 4 "r") 25076 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 25077 (set (match_operand:SI 2 "" "") (match_dup 1)) 25078 (match_dup 4) 25079 (set (match_operand:SI 3 "" "") (match_dup 1))] 25080 "/* determine 1 does not overlap 0 and 2 */" 25081 [(set (match_dup 4) (match_dup 1)) 25082 (set (match_dup 0) (match_dup 4)) 25083 (set (match_dup 2) (match_dup 4))] 25084 (set (match_dup 3) (match_dup 4))] 25085 "") 25086 25087If we had not added the `(match_dup 4)' in the middle of the input 25088sequence, it might have been the case that the register we chose at the 25089beginning of the sequence is killed by the first or second `set'. 25090 25091 25092File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 25093 2509416.19 Instruction Attributes 25095============================ 25096 25097In addition to describing the instruction supported by the target 25098machine, the `md' file also defines a group of "attributes" and a set of 25099values for each. Every generated insn is assigned a value for each 25100attribute. One possible attribute would be the effect that the insn 25101has on the machine's condition code. This attribute can then be used 25102by `NOTICE_UPDATE_CC' to track the condition codes. 25103 25104* Menu: 25105 25106* Defining Attributes:: Specifying attributes and their values. 25107* Expressions:: Valid expressions for attribute values. 25108* Tagging Insns:: Assigning attribute values to insns. 25109* Attr Example:: An example of assigning attributes. 25110* Insn Lengths:: Computing the length of insns. 25111* Constant Attributes:: Defining attributes that are constant. 25112* Delay Slots:: Defining delay slots required for a machine. 25113* Processor pipeline description:: Specifying information for insn scheduling. 25114 25115 25116File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 25117 2511816.19.1 Defining Attributes and their Values 25119-------------------------------------------- 25120 25121The `define_attr' expression is used to define each attribute required 25122by the target machine. It looks like: 25123 25124 (define_attr NAME LIST-OF-VALUES DEFAULT) 25125 25126 NAME is a string specifying the name of the attribute being defined. 25127Some attributes are used in a special way by the rest of the compiler. 25128The `enabled' attribute can be used to conditionally enable or disable 25129insn alternatives (*note Disable Insn Alternatives::). The `predicable' 25130attribute, together with a suitable `define_cond_exec' (*note 25131Conditional Execution::), can be used to automatically generate 25132conditional variants of instruction patterns. The compiler internally 25133uses the names `ce_enabled' and `nonce_enabled', so they should not be 25134used elsewhere as alternative names. 25135 25136 LIST-OF-VALUES is either a string that specifies a comma-separated 25137list of values that can be assigned to the attribute, or a null string 25138to indicate that the attribute takes numeric values. 25139 25140 DEFAULT is an attribute expression that gives the value of this 25141attribute for insns that match patterns whose definition does not 25142include an explicit value for this attribute. *Note Attr Example::, 25143for more information on the handling of defaults. *Note Constant 25144Attributes::, for information on attributes that do not depend on any 25145particular insn. 25146 25147 For each defined attribute, a number of definitions are written to the 25148`insn-attr.h' file. For cases where an explicit set of values is 25149specified for an attribute, the following are defined: 25150 25151 * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 25152 25153 * An enumerated class is defined for `attr_NAME' with elements of 25154 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and 25155 value are first converted to uppercase. 25156 25157 * A function `get_attr_NAME' is defined that is passed an insn and 25158 returns the attribute value for that insn. 25159 25160 For example, if the following is present in the `md' file: 25161 25162 (define_attr "type" "branch,fp,load,store,arith" ...) 25163 25164the following lines will be written to the file `insn-attr.h'. 25165 25166 #define HAVE_ATTR_type 1 25167 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 25168 TYPE_STORE, TYPE_ARITH}; 25169 extern enum attr_type get_attr_type (); 25170 25171 If the attribute takes numeric values, no `enum' type will be defined 25172and the function to obtain the attribute's value will return `int'. 25173 25174 There are attributes which are tied to a specific meaning. These 25175attributes are not free to use for other purposes: 25176 25177`length' 25178 The `length' attribute is used to calculate the length of emitted 25179 code chunks. This is especially important when verifying branch 25180 distances. *Note Insn Lengths::. 25181 25182`enabled' 25183 The `enabled' attribute can be defined to prevent certain 25184 alternatives of an insn definition from being used during code 25185 generation. *Note Disable Insn Alternatives::. 25186 25187 For each of these special attributes, the corresponding 25188`HAVE_ATTR_NAME' `#define' is also written when the attribute is not 25189defined; in that case, it is defined as `0'. 25190 25191 Another way of defining an attribute is to use: 25192 25193 (define_enum_attr "ATTR" "ENUM" DEFAULT) 25194 25195 This works in just the same way as `define_attr', except that the list 25196of values is taken from a separate enumeration called ENUM (*note 25197define_enum::). This form allows you to use the same list of values 25198for several attributes without having to repeat the list each time. 25199For example: 25200 25201 (define_enum "processor" [ 25202 model_a 25203 model_b 25204 ... 25205 ]) 25206 (define_enum_attr "arch" "processor" 25207 (const (symbol_ref "target_arch"))) 25208 (define_enum_attr "tune" "processor" 25209 (const (symbol_ref "target_tune"))) 25210 25211 defines the same attributes as: 25212 25213 (define_attr "arch" "model_a,model_b,..." 25214 (const (symbol_ref "target_arch"))) 25215 (define_attr "tune" "model_a,model_b,..." 25216 (const (symbol_ref "target_tune"))) 25217 25218 but without duplicating the processor list. The second example 25219defines two separate C enums (`attr_arch' and `attr_tune') whereas the 25220first defines a single C enum (`processor'). 25221 25222 25223File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 25224 2522516.19.2 Attribute Expressions 25226----------------------------- 25227 25228RTL expressions used to define attributes use the codes described above 25229plus a few specific to attribute definitions, to be discussed below. 25230Attribute value expressions must have one of the following forms: 25231 25232`(const_int I)' 25233 The integer I specifies the value of a numeric attribute. I must 25234 be non-negative. 25235 25236 The value of a numeric attribute can be specified either with a 25237 `const_int', or as an integer represented as a string in 25238 `const_string', `eq_attr' (see below), `attr', `symbol_ref', 25239 simple arithmetic expressions, and `set_attr' overrides on 25240 specific instructions (*note Tagging Insns::). 25241 25242`(const_string VALUE)' 25243 The string VALUE specifies a constant attribute value. If VALUE 25244 is specified as `"*"', it means that the default value of the 25245 attribute is to be used for the insn containing this expression. 25246 `"*"' obviously cannot be used in the DEFAULT expression of a 25247 `define_attr'. 25248 25249 If the attribute whose value is being specified is numeric, VALUE 25250 must be a string containing a non-negative integer (normally 25251 `const_int' would be used in this case). Otherwise, it must 25252 contain one of the valid values for the attribute. 25253 25254`(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 25255 TEST specifies an attribute test, whose format is defined below. 25256 The value of this expression is TRUE-VALUE if TEST is true, 25257 otherwise it is FALSE-VALUE. 25258 25259`(cond [TEST1 VALUE1 ...] DEFAULT)' 25260 The first operand of this expression is a vector containing an even 25261 number of expressions and consisting of pairs of TEST and VALUE 25262 expressions. The value of the `cond' expression is that of the 25263 VALUE corresponding to the first true TEST expression. If none of 25264 the TEST expressions are true, the value of the `cond' expression 25265 is that of the DEFAULT expression. 25266 25267 TEST expressions can have one of the following forms: 25268 25269`(const_int I)' 25270 This test is true if I is nonzero and false otherwise. 25271 25272`(not TEST)' 25273`(ior TEST1 TEST2)' 25274`(and TEST1 TEST2)' 25275 These tests are true if the indicated logical function is true. 25276 25277`(match_operand:M N PRED CONSTRAINTS)' 25278 This test is true if operand N of the insn whose attribute value 25279 is being determined has mode M (this part of the test is ignored 25280 if M is `VOIDmode') and the function specified by the string PRED 25281 returns a nonzero value when passed operand N and mode M (this 25282 part of the test is ignored if PRED is the null string). 25283 25284 The CONSTRAINTS operand is ignored and should be the null string. 25285 25286`(match_test C-EXPR)' 25287 The test is true if C expression C-EXPR is true. In non-constant 25288 attributes, C-EXPR has access to the following variables: 25289 25290 INSN 25291 The rtl instruction under test. 25292 25293 WHICH_ALTERNATIVE 25294 The `define_insn' alternative that INSN matches. *Note 25295 Output Statement::. 25296 25297 OPERANDS 25298 An array of INSN's rtl operands. 25299 25300 C-EXPR behaves like the condition in a C `if' statement, so there 25301 is no need to explicitly convert the expression into a boolean 0 25302 or 1 value. For example, the following two tests are equivalent: 25303 25304 (match_test "x & 2") 25305 (match_test "(x & 2) != 0") 25306 25307`(le ARITH1 ARITH2)' 25308`(leu ARITH1 ARITH2)' 25309`(lt ARITH1 ARITH2)' 25310`(ltu ARITH1 ARITH2)' 25311`(gt ARITH1 ARITH2)' 25312`(gtu ARITH1 ARITH2)' 25313`(ge ARITH1 ARITH2)' 25314`(geu ARITH1 ARITH2)' 25315`(ne ARITH1 ARITH2)' 25316`(eq ARITH1 ARITH2)' 25317 These tests are true if the indicated comparison of the two 25318 arithmetic expressions is true. Arithmetic expressions are formed 25319 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 25320 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 25321 expressions. 25322 25323 `const_int' and `symbol_ref' are always valid terms (*note Insn 25324 Lengths::,for additional forms). `symbol_ref' is a string 25325 denoting a C expression that yields an `int' when evaluated by the 25326 `get_attr_...' routine. It should normally be a global variable. 25327 25328`(eq_attr NAME VALUE)' 25329 NAME is a string specifying the name of an attribute. 25330 25331 VALUE is a string that is either a valid value for attribute NAME, 25332 a comma-separated list of values, or `!' followed by a value or 25333 list. If VALUE does not begin with a `!', this test is true if 25334 the value of the NAME attribute of the current insn is in the list 25335 specified by VALUE. If VALUE begins with a `!', this test is true 25336 if the attribute's value is _not_ in the specified list. 25337 25338 For example, 25339 25340 (eq_attr "type" "load,store") 25341 25342 is equivalent to 25343 25344 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 25345 25346 If NAME specifies an attribute of `alternative', it refers to the 25347 value of the compiler variable `which_alternative' (*note Output 25348 Statement::) and the values must be small integers. For example, 25349 25350 (eq_attr "alternative" "2,3") 25351 25352 is equivalent to 25353 25354 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 25355 (eq (symbol_ref "which_alternative") (const_int 3))) 25356 25357 Note that, for most attributes, an `eq_attr' test is simplified in 25358 cases where the value of the attribute being tested is known for 25359 all insns matching a particular pattern. This is by far the most 25360 common case. 25361 25362`(attr_flag NAME)' 25363 The value of an `attr_flag' expression is true if the flag 25364 specified by NAME is true for the `insn' currently being scheduled. 25365 25366 NAME is a string specifying one of a fixed set of flags to test. 25367 Test the flags `forward' and `backward' to determine the direction 25368 of a conditional branch. 25369 25370 This example describes a conditional branch delay slot which can 25371 be nullified for forward branches that are taken (annul-true) or 25372 for backward branches which are not taken (annul-false). 25373 25374 (define_delay (eq_attr "type" "cbranch") 25375 [(eq_attr "in_branch_delay" "true") 25376 (and (eq_attr "in_branch_delay" "true") 25377 (attr_flag "forward")) 25378 (and (eq_attr "in_branch_delay" "true") 25379 (attr_flag "backward"))]) 25380 25381 The `forward' and `backward' flags are false if the current `insn' 25382 being scheduled is not a conditional branch. 25383 25384 `attr_flag' is only used during delay slot scheduling and has no 25385 meaning to other passes of the compiler. 25386 25387`(attr NAME)' 25388 The value of another attribute is returned. This is most useful 25389 for numeric attributes, as `eq_attr' and `attr_flag' produce more 25390 efficient code for non-numeric attributes. 25391 25392 25393File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 25394 2539516.19.3 Assigning Attribute Values to Insns 25396------------------------------------------- 25397 25398The value assigned to an attribute of an insn is primarily determined by 25399which pattern is matched by that insn (or which `define_peephole' 25400generated it). Every `define_insn' and `define_peephole' can have an 25401optional last argument to specify the values of attributes for matching 25402insns. The value of any attribute not specified in a particular insn 25403is set to the default value for that attribute, as specified in its 25404`define_attr'. Extensive use of default values for attributes permits 25405the specification of the values for only one or two attributes in the 25406definition of most insn patterns, as seen in the example in the next 25407section. 25408 25409 The optional last argument of `define_insn' and `define_peephole' is a 25410vector of expressions, each of which defines the value for a single 25411attribute. The most general way of assigning an attribute's value is 25412to use a `set' expression whose first operand is an `attr' expression 25413giving the name of the attribute being set. The second operand of the 25414`set' is an attribute expression (*note Expressions::) giving the value 25415of the attribute. 25416 25417 When the attribute value depends on the `alternative' attribute (i.e., 25418which is the applicable alternative in the constraint of the insn), the 25419`set_attr_alternative' expression can be used. It allows the 25420specification of a vector of attribute expressions, one for each 25421alternative. 25422 25423 When the generality of arbitrary attribute expressions is not required, 25424the simpler `set_attr' expression can be used, which allows specifying 25425a string giving either a single attribute value or a list of attribute 25426values, one for each alternative. 25427 25428 The form of each of the above specifications is shown below. In each 25429case, NAME is a string specifying the attribute to be set. 25430 25431`(set_attr NAME VALUE-STRING)' 25432 VALUE-STRING is either a string giving the desired attribute value, 25433 or a string containing a comma-separated list giving the values for 25434 succeeding alternatives. The number of elements must match the 25435 number of alternatives in the constraint of the insn pattern. 25436 25437 Note that it may be useful to specify `*' for some alternative, in 25438 which case the attribute will assume its default value for insns 25439 matching that alternative. 25440 25441`(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 25442 Depending on the alternative of the insn, the value will be one of 25443 the specified values. This is a shorthand for using a `cond' with 25444 tests on the `alternative' attribute. 25445 25446`(set (attr NAME) VALUE)' 25447 The first operand of this `set' must be the special RTL expression 25448 `attr', whose sole operand is a string giving the name of the 25449 attribute being set. VALUE is the value of the attribute. 25450 25451 The following shows three different ways of representing the same 25452attribute value specification: 25453 25454 (set_attr "type" "load,store,arith") 25455 25456 (set_attr_alternative "type" 25457 [(const_string "load") (const_string "store") 25458 (const_string "arith")]) 25459 25460 (set (attr "type") 25461 (cond [(eq_attr "alternative" "1") (const_string "load") 25462 (eq_attr "alternative" "2") (const_string "store")] 25463 (const_string "arith"))) 25464 25465 The `define_asm_attributes' expression provides a mechanism to specify 25466the attributes assigned to insns produced from an `asm' statement. It 25467has the form: 25468 25469 (define_asm_attributes [ATTR-SETS]) 25470 25471where ATTR-SETS is specified the same as for both the `define_insn' and 25472the `define_peephole' expressions. 25473 25474 These values will typically be the "worst case" attribute values. For 25475example, they might indicate that the condition code will be clobbered. 25476 25477 A specification for a `length' attribute is handled specially. The 25478way to compute the length of an `asm' insn is to multiply the length 25479specified in the expression `define_asm_attributes' by the number of 25480machine instructions specified in the `asm' statement, determined by 25481counting the number of semicolons and newlines in the string. 25482Therefore, the value of the `length' attribute specified in a 25483`define_asm_attributes' should be the maximum possible length of a 25484single machine instruction. 25485 25486 25487File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 25488 2548916.19.4 Example of Attribute Specifications 25490------------------------------------------- 25491 25492The judicious use of defaulting is important in the efficient use of 25493insn attributes. Typically, insns are divided into "types" and an 25494attribute, customarily called `type', is used to represent this value. 25495This attribute is normally used only to define the default value for 25496other attributes. An example will clarify this usage. 25497 25498 Assume we have a RISC machine with a condition code and in which only 25499full-word operations are performed in registers. Let us assume that we 25500can divide all insns into loads, stores, (integer) arithmetic 25501operations, floating point operations, and branches. 25502 25503 Here we will concern ourselves with determining the effect of an insn 25504on the condition code and will limit ourselves to the following possible 25505effects: The condition code can be set unpredictably (clobbered), not 25506be changed, be set to agree with the results of the operation, or only 25507changed if the item previously set into the condition code has been 25508modified. 25509 25510 Here is part of a sample `md' file for such a machine: 25511 25512 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 25513 25514 (define_attr "cc" "clobber,unchanged,set,change0" 25515 (cond [(eq_attr "type" "load") 25516 (const_string "change0") 25517 (eq_attr "type" "store,branch") 25518 (const_string "unchanged") 25519 (eq_attr "type" "arith") 25520 (if_then_else (match_operand:SI 0 "" "") 25521 (const_string "set") 25522 (const_string "clobber"))] 25523 (const_string "clobber"))) 25524 25525 (define_insn "" 25526 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 25527 (match_operand:SI 1 "general_operand" "r,m,r"))] 25528 "" 25529 "@ 25530 move %0,%1 25531 load %0,%1 25532 store %0,%1" 25533 [(set_attr "type" "arith,load,store")]) 25534 25535 Note that we assume in the above example that arithmetic operations 25536performed on quantities smaller than a machine word clobber the 25537condition code since they will set the condition code to a value 25538corresponding to the full-word result. 25539 25540 25541File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 25542 2554316.19.5 Computing the Length of an Insn 25544--------------------------------------- 25545 25546For many machines, multiple types of branch instructions are provided, 25547each for different length branch displacements. In most cases, the 25548assembler will choose the correct instruction to use. However, when 25549the assembler cannot do so, GCC can when a special attribute, the 25550`length' attribute, is defined. This attribute must be defined to have 25551numeric values by specifying a null string in its `define_attr'. 25552 25553 In the case of the `length' attribute, two additional forms of 25554arithmetic terms are allowed in test expressions: 25555 25556`(match_dup N)' 25557 This refers to the address of operand N of the current insn, which 25558 must be a `label_ref'. 25559 25560`(pc)' 25561 For non-branch instructions and backward branch instructions, this 25562 refers to the address of the current insn. But for forward branch 25563 instructions, this refers to the address of the next insn, because 25564 the length of the current insn is to be computed. 25565 25566 For normal insns, the length will be determined by value of the 25567`length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 25568patterns, the length is computed as the number of vectors multiplied by 25569the size of each vector. 25570 25571 Lengths are measured in addressable storage units (bytes). 25572 25573 The following macros can be used to refine the length computation: 25574 25575`ADJUST_INSN_LENGTH (INSN, LENGTH)' 25576 If defined, modifies the length assigned to instruction INSN as a 25577 function of the context in which it is used. LENGTH is an lvalue 25578 that contains the initially computed length of the insn and should 25579 be updated with the correct length of the insn. 25580 25581 This macro will normally not be required. A case in which it is 25582 required is the ROMP. On this machine, the size of an `addr_vec' 25583 insn must be increased by two to compensate for the fact that 25584 alignment may be required. 25585 25586 The routine that returns `get_attr_length' (the value of the `length' 25587attribute) can be used by the output routine to determine the form of 25588the branch instruction to be written, as the example below illustrates. 25589 25590 As an example of the specification of variable-length branches, 25591consider the IBM 360. If we adopt the convention that a register will 25592be set to the starting address of a function, we can jump to labels 25593within 4k of the start using a four-byte instruction. Otherwise, we 25594need a six-byte sequence to load the address from memory and then 25595branch to it. 25596 25597 On such a machine, a pattern for a branch instruction might be 25598specified as follows: 25599 25600 (define_insn "jump" 25601 [(set (pc) 25602 (label_ref (match_operand 0 "" "")))] 25603 "" 25604 { 25605 return (get_attr_length (insn) == 4 25606 ? "b %l0" : "l r15,=a(%l0); br r15"); 25607 } 25608 [(set (attr "length") 25609 (if_then_else (lt (match_dup 0) (const_int 4096)) 25610 (const_int 4) 25611 (const_int 6)))]) 25612 25613 25614File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes 25615 2561616.19.6 Constant Attributes 25617--------------------------- 25618 25619A special form of `define_attr', where the expression for the default 25620value is a `const' expression, indicates an attribute that is constant 25621for a given run of the compiler. Constant attributes may be used to 25622specify which variety of processor is used. For example, 25623 25624 (define_attr "cpu" "m88100,m88110,m88000" 25625 (const 25626 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 25627 (symbol_ref "TARGET_88110") (const_string "m88110")] 25628 (const_string "m88000")))) 25629 25630 (define_attr "memory" "fast,slow" 25631 (const 25632 (if_then_else (symbol_ref "TARGET_FAST_MEM") 25633 (const_string "fast") 25634 (const_string "slow")))) 25635 25636 The routine generated for constant attributes has no parameters as it 25637does not depend on any particular insn. RTL expressions used to define 25638the value of a constant attribute may use the `symbol_ref' form, but 25639may not use either the `match_operand' form or `eq_attr' forms 25640involving insn attributes. 25641 25642 25643File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes 25644 2564516.19.7 Delay Slot Scheduling 25646----------------------------- 25647 25648The insn attribute mechanism can be used to specify the requirements for 25649delay slots, if any, on a target machine. An instruction is said to 25650require a "delay slot" if some instructions that are physically after 25651the instruction are executed as if they were located before it. 25652Classic examples are branch and call instructions, which often execute 25653the following instruction before the branch or call is performed. 25654 25655 On some machines, conditional branch instructions can optionally 25656"annul" instructions in the delay slot. This means that the 25657instruction will not be executed for certain branch outcomes. Both 25658instructions that annul if the branch is true and instructions that 25659annul if the branch is false are supported. 25660 25661 Delay slot scheduling differs from instruction scheduling in that 25662determining whether an instruction needs a delay slot is dependent only 25663on the type of instruction being generated, not on data flow between the 25664instructions. See the next section for a discussion of data-dependent 25665instruction scheduling. 25666 25667 The requirement of an insn needing one or more delay slots is indicated 25668via the `define_delay' expression. It has the following form: 25669 25670 (define_delay TEST 25671 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 25672 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 25673 ...]) 25674 25675 TEST is an attribute test that indicates whether this `define_delay' 25676applies to a particular insn. If so, the number of required delay 25677slots is determined by the length of the vector specified as the second 25678argument. An insn placed in delay slot N must satisfy attribute test 25679DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 25680may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 25681specifies which insns in the delay slot may be annulled if the branch 25682is false. If annulling is not supported for that delay slot, `(nil)' 25683should be coded. 25684 25685 For example, in the common case where branch and call insns require a 25686single delay slot, which may contain any insn other than a branch or 25687call, the following would be placed in the `md' file: 25688 25689 (define_delay (eq_attr "type" "branch,call") 25690 [(eq_attr "type" "!branch,call") (nil) (nil)]) 25691 25692 Multiple `define_delay' expressions may be specified. In this case, 25693each such expression specifies different delay slot requirements and 25694there must be no insn for which tests in two `define_delay' expressions 25695are both true. 25696 25697 For example, if we have a machine that requires one delay slot for 25698branches but two for calls, no delay slot can contain a branch or call 25699insn, and any valid insn in the delay slot for the branch can be 25700annulled if the branch is true, we might represent this as follows: 25701 25702 (define_delay (eq_attr "type" "branch") 25703 [(eq_attr "type" "!branch,call") 25704 (eq_attr "type" "!branch,call") 25705 (nil)]) 25706 25707 (define_delay (eq_attr "type" "call") 25708 [(eq_attr "type" "!branch,call") (nil) (nil) 25709 (eq_attr "type" "!branch,call") (nil) (nil)]) 25710 25711 25712File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 25713 2571416.19.8 Specifying processor pipeline description 25715------------------------------------------------- 25716 25717To achieve better performance, most modern processors (super-pipelined, 25718superscalar RISC, and VLIW processors) have many "functional units" on 25719which several instructions can be executed simultaneously. An 25720instruction starts execution if its issue conditions are satisfied. If 25721not, the instruction is stalled until its conditions are satisfied. 25722Such "interlock (pipeline) delay" causes interruption of the fetching 25723of successor instructions (or demands nop instructions, e.g. for some 25724MIPS processors). 25725 25726 There are two major kinds of interlock delays in modern processors. 25727The first one is a data dependence delay determining "instruction 25728latency time". The instruction execution is not started until all 25729source data have been evaluated by prior instructions (there are more 25730complex cases when the instruction execution starts even when the data 25731are not available but will be ready in given time after the instruction 25732execution start). Taking the data dependence delays into account is 25733simple. The data dependence (true, output, and anti-dependence) delay 25734between two instructions is given by a constant. In most cases this 25735approach is adequate. The second kind of interlock delays is a 25736reservation delay. The reservation delay means that two instructions 25737under execution will be in need of shared processors resources, i.e. 25738buses, internal registers, and/or functional units, which are reserved 25739for some time. Taking this kind of delay into account is complex 25740especially for modern RISC processors. 25741 25742 The task of exploiting more processor parallelism is solved by an 25743instruction scheduler. For a better solution to this problem, the 25744instruction scheduler has to have an adequate description of the 25745processor parallelism (or "pipeline description"). GCC machine 25746descriptions describe processor parallelism and functional unit 25747reservations for groups of instructions with the aid of "regular 25748expressions". 25749 25750 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 25751figure out the possibility of the instruction issue by the processor on 25752a given simulated processor cycle. The pipeline hazard recognizer is 25753automatically generated from the processor pipeline description. The 25754pipeline hazard recognizer generated from the machine description is 25755based on a deterministic finite state automaton (DFA): the instruction 25756issue is possible if there is a transition from one automaton state to 25757another one. This algorithm is very fast, and furthermore, its speed 25758is not dependent on processor complexity(1). 25759 25760 The rest of this section describes the directives that constitute an 25761automaton-based processor pipeline description. The order of these 25762constructions within the machine description file is not important. 25763 25764 The following optional construction describes names of automata 25765generated and used for the pipeline hazards recognition. Sometimes the 25766generated finite state automaton used by the pipeline hazard recognizer 25767is large. If we use more than one automaton and bind functional units 25768to the automata, the total size of the automata is usually less than 25769the size of the single automaton. If there is no one such 25770construction, only one finite state automaton is generated. 25771 25772 (define_automaton AUTOMATA-NAMES) 25773 25774 AUTOMATA-NAMES is a string giving names of the automata. The names 25775are separated by commas. All the automata should have unique names. 25776The automaton name is used in the constructions `define_cpu_unit' and 25777`define_query_cpu_unit'. 25778 25779 Each processor functional unit used in the description of instruction 25780reservations should be described by the following construction. 25781 25782 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 25783 25784 UNIT-NAMES is a string giving the names of the functional units 25785separated by commas. Don't use name `nothing', it is reserved for 25786other goals. 25787 25788 AUTOMATON-NAME is a string giving the name of the automaton with which 25789the unit is bound. The automaton should be described in construction 25790`define_automaton'. You should give "automaton-name", if there is a 25791defined automaton. 25792 25793 The assignment of units to automata are constrained by the uses of the 25794units in insn reservations. The most important constraint is: if a 25795unit reservation is present on a particular cycle of an alternative for 25796an insn reservation, then some unit from the same automaton must be 25797present on the same cycle for the other alternatives of the insn 25798reservation. The rest of the constraints are mentioned in the 25799description of the subsequent constructions. 25800 25801 The following construction describes CPU functional units analogously 25802to `define_cpu_unit'. The reservation of such units can be queried for 25803an automaton state. The instruction scheduler never queries 25804reservation of functional units for given automaton state. So as a 25805rule, you don't need this construction. This construction could be 25806used for future code generation goals (e.g. to generate VLIW insn 25807templates). 25808 25809 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 25810 25811 UNIT-NAMES is a string giving names of the functional units separated 25812by commas. 25813 25814 AUTOMATON-NAME is a string giving the name of the automaton with which 25815the unit is bound. 25816 25817 The following construction is the major one to describe pipeline 25818characteristics of an instruction. 25819 25820 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 25821 CONDITION REGEXP) 25822 25823 DEFAULT_LATENCY is a number giving latency time of the instruction. 25824There is an important difference between the old description and the 25825automaton based pipeline description. The latency time is used for all 25826dependencies when we use the old description. In the automaton based 25827pipeline description, the given latency time is only used for true 25828dependencies. The cost of anti-dependencies is always zero and the 25829cost of output dependencies is the difference between latency times of 25830the producing and consuming insns (if the difference is negative, the 25831cost is considered to be zero). You can always change the default 25832costs for any description by using the target hook 25833`TARGET_SCHED_ADJUST_COST' (*note Scheduling::). 25834 25835 INSN-NAME is a string giving the internal name of the insn. The 25836internal names are used in constructions `define_bypass' and in the 25837automaton description file generated for debugging. The internal name 25838has nothing in common with the names in `define_insn'. It is a good 25839practice to use insn classes described in the processor manual. 25840 25841 CONDITION defines what RTL insns are described by this construction. 25842You should remember that you will be in trouble if CONDITION for two or 25843more different `define_insn_reservation' constructions is TRUE for an 25844insn. In this case what reservation will be used for the insn is not 25845defined. Such cases are not checked during generation of the pipeline 25846hazards recognizer because in general recognizing that two conditions 25847may have the same value is quite difficult (especially if the conditions 25848contain `symbol_ref'). It is also not checked during the pipeline 25849hazard recognizer work because it would slow down the recognizer 25850considerably. 25851 25852 REGEXP is a string describing the reservation of the cpu's functional 25853units by the instruction. The reservations are described by a regular 25854expression according to the following syntax: 25855 25856 regexp = regexp "," oneof 25857 | oneof 25858 25859 oneof = oneof "|" allof 25860 | allof 25861 25862 allof = allof "+" repeat 25863 | repeat 25864 25865 repeat = element "*" number 25866 | element 25867 25868 element = cpu_function_unit_name 25869 | reservation_name 25870 | result_name 25871 | "nothing" 25872 | "(" regexp ")" 25873 25874 * `,' is used for describing the start of the next cycle in the 25875 reservation. 25876 25877 * `|' is used for describing a reservation described by the first 25878 regular expression *or* a reservation described by the second 25879 regular expression *or* etc. 25880 25881 * `+' is used for describing a reservation described by the first 25882 regular expression *and* a reservation described by the second 25883 regular expression *and* etc. 25884 25885 * `*' is used for convenience and simply means a sequence in which 25886 the regular expression are repeated NUMBER times with cycle 25887 advancing (see `,'). 25888 25889 * `cpu_function_unit_name' denotes reservation of the named 25890 functional unit. 25891 25892 * `reservation_name' -- see description of construction 25893 `define_reservation'. 25894 25895 * `nothing' denotes no unit reservations. 25896 25897 Sometimes unit reservations for different insns contain common parts. 25898In such case, you can simplify the pipeline description by describing 25899the common part by the following construction 25900 25901 (define_reservation RESERVATION-NAME REGEXP) 25902 25903 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 25904names and reservation names are in the same name space. So the 25905reservation names should be different from the functional unit names 25906and can not be the reserved name `nothing'. 25907 25908 The following construction is used to describe exceptions in the 25909latency time for given instruction pair. This is so called bypasses. 25910 25911 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 25912 [GUARD]) 25913 25914 NUMBER defines when the result generated by the instructions given in 25915string OUT_INSN_NAMES will be ready for the instructions given in 25916string IN_INSN_NAMES. Each of these strings is a comma-separated list 25917of filename-style globs and they refer to the names of 25918`define_insn_reservation's. For example: 25919 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 25920 defines a bypass between instructions that start with `cpu1_load_' or 25921`cpu1_store_' and those that start with `cpu1_load_'. 25922 25923 GUARD is an optional string giving the name of a C function which 25924defines an additional guard for the bypass. The function will get the 25925two insns as parameters. If the function returns zero the bypass will 25926be ignored for this case. The additional guard is necessary to 25927recognize complicated bypasses, e.g. when the consumer is only an 25928address of insn `store' (not a stored value). 25929 25930 If there are more one bypass with the same output and input insns, the 25931chosen bypass is the first bypass with a guard in description whose 25932guard function returns nonzero. If there is no such bypass, then 25933bypass without the guard function is chosen. 25934 25935 The following five constructions are usually used to describe VLIW 25936processors, or more precisely, to describe a placement of small 25937instructions into VLIW instruction slots. They can be used for RISC 25938processors, too. 25939 25940 (exclusion_set UNIT-NAMES UNIT-NAMES) 25941 (presence_set UNIT-NAMES PATTERNS) 25942 (final_presence_set UNIT-NAMES PATTERNS) 25943 (absence_set UNIT-NAMES PATTERNS) 25944 (final_absence_set UNIT-NAMES PATTERNS) 25945 25946 UNIT-NAMES is a string giving names of functional units separated by 25947commas. 25948 25949 PATTERNS is a string giving patterns of functional units separated by 25950comma. Currently pattern is one unit or units separated by 25951white-spaces. 25952 25953 The first construction (`exclusion_set') means that each functional 25954unit in the first string can not be reserved simultaneously with a unit 25955whose name is in the second string and vice versa. For example, the 25956construction is useful for describing processors (e.g. some SPARC 25957processors) with a fully pipelined floating point functional unit which 25958can execute simultaneously only single floating point insns or only 25959double floating point insns. 25960 25961 The second construction (`presence_set') means that each functional 25962unit in the first string can not be reserved unless at least one of 25963pattern of units whose names are in the second string is reserved. 25964This is an asymmetric relation. For example, it is useful for 25965description that VLIW `slot1' is reserved after `slot0' reservation. 25966We could describe it by the following construction 25967 25968 (presence_set "slot1" "slot0") 25969 25970 Or `slot1' is reserved only after `slot0' and unit `b0' reservation. 25971In this case we could write 25972 25973 (presence_set "slot1" "slot0 b0") 25974 25975 The third construction (`final_presence_set') is analogous to 25976`presence_set'. The difference between them is when checking is done. 25977When an instruction is issued in given automaton state reflecting all 25978current and planned unit reservations, the automaton state is changed. 25979The first state is a source state, the second one is a result state. 25980Checking for `presence_set' is done on the source state reservation, 25981checking for `final_presence_set' is done on the result reservation. 25982This construction is useful to describe a reservation which is actually 25983two subsequent reservations. For example, if we use 25984 25985 (presence_set "slot1" "slot0") 25986 25987 the following insn will be never issued (because `slot1' requires 25988`slot0' which is absent in the source state). 25989 25990 (define_reservation "insn_and_nop" "slot0 + slot1") 25991 25992 but it can be issued if we use analogous `final_presence_set'. 25993 25994 The forth construction (`absence_set') means that each functional unit 25995in the first string can be reserved only if each pattern of units whose 25996names are in the second string is not reserved. This is an asymmetric 25997relation (actually `exclusion_set' is analogous to this one but it is 25998symmetric). For example it might be useful in a VLIW description to 25999say that `slot0' cannot be reserved after either `slot1' or `slot2' 26000have been reserved. This can be described as: 26001 26002 (absence_set "slot0" "slot1, slot2") 26003 26004 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved 26005or `slot1' and unit `b1' are reserved. In this case we could write 26006 26007 (absence_set "slot2" "slot0 b0, slot1 b1") 26008 26009 All functional units mentioned in a set should belong to the same 26010automaton. 26011 26012 The last construction (`final_absence_set') is analogous to 26013`absence_set' but checking is done on the result (state) reservation. 26014See comments for `final_presence_set'. 26015 26016 You can control the generator of the pipeline hazard recognizer with 26017the following construction. 26018 26019 (automata_option OPTIONS) 26020 26021 OPTIONS is a string giving options which affect the generated code. 26022Currently there are the following options: 26023 26024 * "no-minimization" makes no minimization of the automaton. This is 26025 only worth to do when we are debugging the description and need to 26026 look more accurately at reservations of states. 26027 26028 * "time" means printing time statistics about the generation of 26029 automata. 26030 26031 * "stats" means printing statistics about the generated automata 26032 such as the number of DFA states, NDFA states and arcs. 26033 26034 * "v" means a generation of the file describing the result automata. 26035 The file has suffix `.dfa' and can be used for the description 26036 verification and debugging. 26037 26038 * "w" means a generation of warning instead of error for 26039 non-critical errors. 26040 26041 * "no-comb-vect" prevents the automaton generator from generating 26042 two data structures and comparing them for space efficiency. Using 26043 a comb vector to represent transitions may be better, but it can be 26044 very expensive to construct. This option is useful if the build 26045 process spends an unacceptably long time in genautomata. 26046 26047 * "ndfa" makes nondeterministic finite state automata. This affects 26048 the treatment of operator `|' in the regular expressions. The 26049 usual treatment of the operator is to try the first alternative 26050 and, if the reservation is not possible, the second alternative. 26051 The nondeterministic treatment means trying all alternatives, some 26052 of them may be rejected by reservations in the subsequent insns. 26053 26054 * "collapse-ndfa" modifies the behaviour of the generator when 26055 producing an automaton. An additional state transition to 26056 collapse a nondeterministic NDFA state to a deterministic DFA 26057 state is generated. It can be triggered by passing `const0_rtx' to 26058 state_transition. In such an automaton, cycle advance transitions 26059 are available only for these collapsed states. This option is 26060 useful for ports that want to use the `ndfa' option, but also want 26061 to use `define_query_cpu_unit' to assign units to insns issued in 26062 a cycle. 26063 26064 * "progress" means output of a progress bar showing how many states 26065 were generated so far for automaton being processed. This is 26066 useful during debugging a DFA description. If you see too many 26067 generated states, you could interrupt the generator of the pipeline 26068 hazard recognizer and try to figure out a reason for generation of 26069 the huge automaton. 26070 26071 As an example, consider a superscalar RISC machine which can issue 26072three insns (two integer insns and one floating point insn) on the 26073cycle but can finish only two insns. To describe this, we define the 26074following functional units. 26075 26076 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 26077 (define_cpu_unit "port0, port1") 26078 26079 All simple integer insns can be executed in any integer pipeline and 26080their result is ready in two cycles. The simple integer insns are 26081issued into the first pipeline unless it is reserved, otherwise they 26082are issued into the second pipeline. Integer division and 26083multiplication insns can be executed only in the second integer 26084pipeline and their results are ready correspondingly in 8 and 4 cycles. 26085The integer division is not pipelined, i.e. the subsequent integer 26086division insn can not be issued until the current division insn 26087finished. Floating point insns are fully pipelined and their results 26088are ready in 3 cycles. Where the result of a floating point insn is 26089used by an integer insn, an additional delay of one cycle is incurred. 26090To describe all of this we could specify 26091 26092 (define_cpu_unit "div") 26093 26094 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26095 "(i0_pipeline | i1_pipeline), (port0 | port1)") 26096 26097 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 26098 "i1_pipeline, nothing*2, (port0 | port1)") 26099 26100 (define_insn_reservation "div" 8 (eq_attr "type" "div") 26101 "i1_pipeline, div*7, div + (port0 | port1)") 26102 26103 (define_insn_reservation "float" 3 (eq_attr "type" "float") 26104 "f_pipeline, nothing, (port0 | port1)) 26105 26106 (define_bypass 4 "float" "simple,mult,div") 26107 26108 To simplify the description we could describe the following reservation 26109 26110 (define_reservation "finish" "port0|port1") 26111 26112 and use it in all `define_insn_reservation' as in the following 26113construction 26114 26115 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26116 "(i0_pipeline | i1_pipeline), finish") 26117 26118 ---------- Footnotes ---------- 26119 26120 (1) However, the size of the automaton depends on processor 26121complexity. To limit this effect, machine descriptions can split 26122orthogonal parts of the machine description among several automata: but 26123then, since each of these must be stepped independently, this does 26124cause a small decrease in the algorithm's performance. 26125 26126 26127File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 26128 2612916.20 Conditional Execution 26130=========================== 26131 26132A number of architectures provide for some form of conditional 26133execution, or predication. The hallmark of this feature is the ability 26134to nullify most of the instructions in the instruction set. When the 26135instruction set is large and not entirely symmetric, it can be quite 26136tedious to describe these forms directly in the `.md' file. An 26137alternative is the `define_cond_exec' template. 26138 26139 (define_cond_exec 26140 [PREDICATE-PATTERN] 26141 "CONDITION" 26142 "OUTPUT-TEMPLATE") 26143 26144 PREDICATE-PATTERN is the condition that must be true for the insn to 26145be executed at runtime and should match a relational operator. One can 26146use `match_operator' to match several relational operators at once. 26147Any `match_operand' operands must have no more than one alternative. 26148 26149 CONDITION is a C expression that must be true for the generated 26150pattern to match. 26151 26152 OUTPUT-TEMPLATE is a string similar to the `define_insn' output 26153template (*note Output Template::), except that the `*' and `@' special 26154cases do not apply. This is only useful if the assembly text for the 26155predicate is a simple prefix to the main insn. In order to handle the 26156general case, there is a global variable `current_insn_predicate' that 26157will contain the entire predicate if the current insn is predicated, 26158and will otherwise be `NULL'. 26159 26160 When `define_cond_exec' is used, an implicit reference to the 26161`predicable' instruction attribute is made. *Note Insn Attributes::. 26162This attribute must be a boolean (i.e. have exactly two elements in its 26163LIST-OF-VALUES), with the possible values being `no' and `yes'. The 26164default and all uses in the insns must be a simple constant, not a 26165complex expressions. It may, however, depend on the alternative, by 26166using a comma-separated list of values. If that is the case, the port 26167should also define an `enabled' attribute (*note Disable Insn 26168Alternatives::), which should also allow only `no' and `yes' as its 26169values. 26170 26171 For each `define_insn' for which the `predicable' attribute is true, a 26172new `define_insn' pattern will be generated that matches a predicated 26173version of the instruction. For example, 26174 26175 (define_insn "addsi" 26176 [(set (match_operand:SI 0 "register_operand" "r") 26177 (plus:SI (match_operand:SI 1 "register_operand" "r") 26178 (match_operand:SI 2 "register_operand" "r")))] 26179 "TEST1" 26180 "add %2,%1,%0") 26181 26182 (define_cond_exec 26183 [(ne (match_operand:CC 0 "register_operand" "c") 26184 (const_int 0))] 26185 "TEST2" 26186 "(%0)") 26187 26188generates a new pattern 26189 26190 (define_insn "" 26191 [(cond_exec 26192 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 26193 (set (match_operand:SI 0 "register_operand" "r") 26194 (plus:SI (match_operand:SI 1 "register_operand" "r") 26195 (match_operand:SI 2 "register_operand" "r"))))] 26196 "(TEST2) && (TEST1)" 26197 "(%3) add %2,%1,%0") 26198 26199 26200File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 26201 2620216.21 RTL Templates Transformations 26203=================================== 26204 26205For some hardware architectures there are common cases when the RTL 26206templates for the instructions can be derived from the other RTL 26207templates using simple transformations. E.g., `i386.md' contains an 26208RTL template for the ordinary `sub' instruction-- `*subsi_1', and for 26209the `sub' instruction with subsequent zero-extension--`*subsi_1_zext'. 26210Such cases can be easily implemented by a single meta-template capable 26211of generating a modified case based on the initial one: 26212 26213 (define_subst "NAME" 26214 [INPUT-TEMPLATE] 26215 "CONDITION" 26216 [OUTPUT-TEMPLATE]) 26217 INPUT-TEMPLATE is a pattern describing the source RTL template, which 26218will be transformed. 26219 26220 CONDITION is a C expression that is conjunct with the condition from 26221the input-template to generate a condition to be used in the 26222output-template. 26223 26224 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 26225template. 26226 26227 `define_subst' mechanism is tightly coupled with the notion of the 26228subst attribute (*note Subst Iterators::). The use of `define_subst' 26229is triggered by a reference to a subst attribute in the transforming 26230RTL template. This reference initiates duplication of the source RTL 26231template and substitution of the attributes with their values. The 26232source RTL template is left unchanged, while the copy is transformed by 26233`define_subst'. This transformation can fail in the case when the 26234source RTL template is not matched against the input-template of the 26235`define_subst'. In such case the copy is deleted. 26236 26237 `define_subst' can be used only in `define_insn' and `define_expand', 26238it cannot be used in other expressions (e.g. in 26239`define_insn_and_split'). 26240 26241* Menu: 26242 26243* Define Subst Example:: Example of `define_subst' work. 26244* Define Subst Pattern Matching:: Process of template comparison. 26245* Define Subst Output Template:: Generation of output template. 26246 26247 26248File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 26249 2625016.21.1 `define_subst' Example 26251------------------------------ 26252 26253To illustrate how `define_subst' works, let us examine a simple 26254template transformation. 26255 26256 Suppose there are two kinds of instructions: one that touches flags and 26257the other that does not. The instructions of the second type could be 26258generated with the following `define_subst': 26259 26260 (define_subst "add_clobber_subst" 26261 [(set (match_operand:SI 0 "" "") 26262 (match_operand:SI 1 "" ""))] 26263 "" 26264 [(set (match_dup 0) 26265 (match_dup 1)) 26266 (clobber (reg:CC FLAGS_REG))] 26267 26268 This `define_subst' can be applied to any RTL pattern containing `set' 26269of mode SI and generates a copy with clobber when it is applied. 26270 26271 Assume there is an RTL template for a `max' instruction to be used in 26272`define_subst' mentioned above: 26273 26274 (define_insn "maxsi" 26275 [(set (match_operand:SI 0 "register_operand" "=r") 26276 (max:SI 26277 (match_operand:SI 1 "register_operand" "r") 26278 (match_operand:SI 2 "register_operand" "r")))] 26279 "" 26280 "max\t{%2, %1, %0|%0, %1, %2}" 26281 [...]) 26282 26283 To mark the RTL template for `define_subst' application, 26284subst-attributes are used. They should be declared in advance: 26285 26286 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 26287 26288 Here `add_clobber_name' is the attribute name, `add_clobber_subst' is 26289the name of the corresponding `define_subst', the third argument 26290(`_noclobber') is the attribute value that would be substituted into 26291the unchanged version of the source RTL template, and the last argument 26292(`_clobber') is the value that would be substituted into the second, 26293transformed, version of the RTL template. 26294 26295 Once the subst-attribute has been defined, it should be used in RTL 26296templates which need to be processed by the `define_subst'. So, the 26297original RTL template should be changed: 26298 26299 (define_insn "maxsi<add_clobber_name>" 26300 [(set (match_operand:SI 0 "register_operand" "=r") 26301 (max:SI 26302 (match_operand:SI 1 "register_operand" "r") 26303 (match_operand:SI 2 "register_operand" "r")))] 26304 "" 26305 "max\t{%2, %1, %0|%0, %1, %2}" 26306 [...]) 26307 26308 The result of the `define_subst' usage would look like the following: 26309 26310 (define_insn "maxsi_noclobber" 26311 [(set (match_operand:SI 0 "register_operand" "=r") 26312 (max:SI 26313 (match_operand:SI 1 "register_operand" "r") 26314 (match_operand:SI 2 "register_operand" "r")))] 26315 "" 26316 "max\t{%2, %1, %0|%0, %1, %2}" 26317 [...]) 26318 (define_insn "maxsi_clobber" 26319 [(set (match_operand:SI 0 "register_operand" "=r") 26320 (max:SI 26321 (match_operand:SI 1 "register_operand" "r") 26322 (match_operand:SI 2 "register_operand" "r"))) 26323 (clobber (reg:CC FLAGS_REG))] 26324 "" 26325 "max\t{%2, %1, %0|%0, %1, %2}" 26326 [...]) 26327 26328 26329File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 26330 2633116.21.2 Pattern Matching in `define_subst' 26332------------------------------------------ 26333 26334All expressions, allowed in `define_insn' or `define_expand', are 26335allowed in the input-template of `define_subst', except 26336`match_par_dup', `match_scratch', `match_parallel'. The meanings of 26337expressions in the input-template were changed: 26338 26339 `match_operand' matches any expression (possibly, a subtree in 26340RTL-template), if modes of the `match_operand' and this expression are 26341the same, or mode of the `match_operand' is `VOIDmode', or this 26342expression is `match_dup', `match_op_dup'. If the expression is 26343`match_operand' too, and predicate of `match_operand' from the input 26344pattern is not empty, then the predicates are compared. That can be 26345used for more accurate filtering of accepted RTL-templates. 26346 26347 `match_operator' matches common operators (like `plus', `minus'), 26348`unspec', `unspec_volatile' operators and `match_operator's from the 26349original pattern if the modes match and `match_operator' from the input 26350pattern has the same number of operands as the operator from the 26351original pattern. 26352 26353 26354File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 26355 2635616.21.3 Generation of output template in `define_subst' 26357------------------------------------------------------- 26358 26359If all necessary checks for `define_subst' application pass, a new 26360RTL-pattern, based on the output-template, is created to replace the old 26361template. Like in input-patterns, meanings of some RTL expressions are 26362changed when they are used in output-patterns of a `define_subst'. 26363Thus, `match_dup' is used for copying the whole expression from the 26364original pattern, which matched corresponding `match_operand' from the 26365input pattern. 26366 26367 `match_dup N' is used in the output template to be replaced with the 26368expression from the original pattern, which matched `match_operand N' 26369from the input pattern. As a consequence, `match_dup' cannot be used 26370to point to `match_operand's from the output pattern, it should always 26371refer to a `match_operand' from the input pattern. 26372 26373 In the output template one can refer to the expressions from the 26374original pattern and create new ones. For instance, some operands could 26375be added by means of standard `match_operand'. 26376 26377 After replacing `match_dup' with some RTL-subtree from the original 26378pattern, it could happen that several `match_operand's in the output 26379pattern have the same indexes. It is unknown, how many and what 26380indexes would be used in the expression which would replace 26381`match_dup', so such conflicts in indexes are inevitable. To overcome 26382this issue, `match_operands' and `match_operators', which were 26383introduced into the output pattern, are renumerated when all 26384`match_dup's are replaced. 26385 26386 Number of alternatives in `match_operand's introduced into the output 26387template `M' could differ from the number of alternatives in the 26388original pattern `N', so in the resultant pattern there would be `N*M' 26389alternatives. Thus, constraints from the original pattern would be 26390duplicated `N' times, constraints from the output pattern would be 26391duplicated `M' times, producing all possible combinations. 26392 26393 26394File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 26395 2639616.22 Constant Definitions 26397========================== 26398 26399Using literal constants inside instruction patterns reduces legibility 26400and can be a maintenance problem. 26401 26402 To overcome this problem, you may use the `define_constants' 26403expression. It contains a vector of name-value pairs. From that point 26404on, wherever any of the names appears in the MD file, it is as if the 26405corresponding value had been written instead. You may use 26406`define_constants' multiple times; each appearance adds more constants 26407to the table. It is an error to redefine a constant with a different 26408value. 26409 26410 To come back to the a29k load multiple example, instead of 26411 26412 (define_insn "" 26413 [(match_parallel 0 "load_multiple_operation" 26414 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 26415 (match_operand:SI 2 "memory_operand" "m")) 26416 (use (reg:SI 179)) 26417 (clobber (reg:SI 179))])] 26418 "" 26419 "loadm 0,0,%1,%2") 26420 26421 You could write: 26422 26423 (define_constants [ 26424 (R_BP 177) 26425 (R_FC 178) 26426 (R_CR 179) 26427 (R_Q 180) 26428 ]) 26429 26430 (define_insn "" 26431 [(match_parallel 0 "load_multiple_operation" 26432 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 26433 (match_operand:SI 2 "memory_operand" "m")) 26434 (use (reg:SI R_CR)) 26435 (clobber (reg:SI R_CR))])] 26436 "" 26437 "loadm 0,0,%1,%2") 26438 26439 The constants that are defined with a define_constant are also output 26440in the insn-codes.h header file as #defines. 26441 26442 You can also use the machine description file to define enumerations. 26443Like the constants defined by `define_constant', these enumerations are 26444visible to both the machine description file and the main C code. 26445 26446 The syntax is as follows: 26447 26448 (define_c_enum "NAME" [ 26449 VALUE0 26450 VALUE1 26451 ... 26452 VALUEN 26453 ]) 26454 26455 This definition causes the equivalent of the following C code to appear 26456in `insn-constants.h': 26457 26458 enum NAME { 26459 VALUE0 = 0, 26460 VALUE1 = 1, 26461 ... 26462 VALUEN = N 26463 }; 26464 #define NUM_CNAME_VALUES (N + 1) 26465 26466 where CNAME is the capitalized form of NAME. It also makes each 26467VALUEI available in the machine description file, just as if it had 26468been declared with: 26469 26470 (define_constants [(VALUEI I)]) 26471 26472 Each VALUEI is usually an upper-case identifier and usually begins 26473with CNAME. 26474 26475 You can split the enumeration definition into as many statements as 26476you like. The above example is directly equivalent to: 26477 26478 (define_c_enum "NAME" [VALUE0]) 26479 (define_c_enum "NAME" [VALUE1]) 26480 ... 26481 (define_c_enum "NAME" [VALUEN]) 26482 26483 Splitting the enumeration helps to improve the modularity of each 26484individual `.md' file. For example, if a port defines its 26485synchronization instructions in a separate `sync.md' file, it is 26486convenient to define all synchronization-specific enumeration values in 26487`sync.md' rather than in the main `.md' file. 26488 26489 Some enumeration names have special significance to GCC: 26490 26491`unspecv' 26492 If an enumeration called `unspecv' is defined, GCC will use it 26493 when printing out `unspec_volatile' expressions. For example: 26494 26495 (define_c_enum "unspecv" [ 26496 UNSPECV_BLOCKAGE 26497 ]) 26498 26499 causes GCC to print `(unspec_volatile ... 0)' as: 26500 26501 (unspec_volatile ... UNSPECV_BLOCKAGE) 26502 26503`unspec' 26504 If an enumeration called `unspec' is defined, GCC will use it when 26505 printing out `unspec' expressions. GCC will also use it when 26506 printing out `unspec_volatile' expressions unless an `unspecv' 26507 enumeration is also defined. You can therefore decide whether to 26508 keep separate enumerations for volatile and non-volatile 26509 expressions or whether to use the same enumeration for both. 26510 26511 Another way of defining an enumeration is to use `define_enum': 26512 26513 (define_enum "NAME" [ 26514 VALUE0 26515 VALUE1 26516 ... 26517 VALUEN 26518 ]) 26519 26520 This directive implies: 26521 26522 (define_c_enum "NAME" [ 26523 CNAME_CVALUE0 26524 CNAME_CVALUE1 26525 ... 26526 CNAME_CVALUEN 26527 ]) 26528 26529 where CVALUEI is the capitalized form of VALUEI. However, unlike 26530`define_c_enum', the enumerations defined by `define_enum' can be used 26531in attribute specifications (*note define_enum_attr::). 26532 26533 26534File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 26535 2653616.23 Iterators 26537=============== 26538 26539Ports often need to define similar patterns for more than one machine 26540mode or for more than one rtx code. GCC provides some simple iterator 26541facilities to make this process easier. 26542 26543* Menu: 26544 26545* Mode Iterators:: Generating variations of patterns for different modes. 26546* Code Iterators:: Doing the same for codes. 26547* Int Iterators:: Doing the same for integers. 26548* Subst Iterators:: Generating variations of patterns for define_subst. 26549 26550 26551File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 26552 2655316.23.1 Mode Iterators 26554---------------------- 26555 26556Ports often need to define similar patterns for two or more different 26557modes. For example: 26558 26559 * If a processor has hardware support for both single and double 26560 floating-point arithmetic, the `SFmode' patterns tend to be very 26561 similar to the `DFmode' ones. 26562 26563 * If a port uses `SImode' pointers in one configuration and `DImode' 26564 pointers in another, it will usually have very similar `SImode' 26565 and `DImode' patterns for manipulating pointers. 26566 26567 Mode iterators allow several patterns to be instantiated from one 26568`.md' file template. They can be used with any type of rtx-based 26569construct, such as a `define_insn', `define_split', or 26570`define_peephole2'. 26571 26572* Menu: 26573 26574* Defining Mode Iterators:: Defining a new mode iterator. 26575* Substitutions:: Combining mode iterators with substitutions 26576* Examples:: Examples 26577 26578 26579File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 26580 2658116.23.1.1 Defining Mode Iterators 26582................................. 26583 26584The syntax for defining a mode iterator is: 26585 26586 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 26587 26588 This allows subsequent `.md' file constructs to use the mode suffix 26589`:NAME'. Every construct that does so will be expanded N times, once 26590with every use of `:NAME' replaced by `:MODE1', once with every use 26591replaced by `:MODE2', and so on. In the expansion for a particular 26592MODEI, every C condition will also require that CONDI be true. 26593 26594 For example: 26595 26596 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 26597 26598 defines a new mode suffix `:P'. Every construct that uses `:P' will 26599be expanded twice, once with every `:P' replaced by `:SI' and once with 26600every `:P' replaced by `:DI'. The `:SI' version will only apply if 26601`Pmode == SImode' and the `:DI' version will only apply if `Pmode == 26602DImode'. 26603 26604 As with other `.md' conditions, an empty string is treated as "always 26605true". `(MODE "")' can also be abbreviated to `MODE'. For example: 26606 26607 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 26608 26609 means that the `:DI' expansion only applies if `TARGET_64BIT' but that 26610the `:SI' expansion has no such constraint. 26611 26612 Iterators are applied in the order they are defined. This can be 26613significant if two iterators are used in a construct that requires 26614substitutions. *Note Substitutions::. 26615 26616 26617File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 26618 2661916.23.1.2 Substitution in Mode Iterators 26620........................................ 26621 26622If an `.md' file construct uses mode iterators, each version of the 26623construct will often need slightly different strings or modes. For 26624example: 26625 26626 * When a `define_expand' defines several `addM3' patterns (*note 26627 Standard Names::), each expander will need to use the appropriate 26628 mode name for M. 26629 26630 * When a `define_insn' defines several instruction patterns, each 26631 instruction will often use a different assembler mnemonic. 26632 26633 * When a `define_insn' requires operands with different modes, using 26634 an iterator for one of the operand modes usually requires a 26635 specific mode for the other operand(s). 26636 26637 GCC supports such variations through a system of "mode attributes". 26638There are two standard attributes: `mode', which is the name of the 26639mode in lower case, and `MODE', which is the same thing in upper case. 26640You can define other attributes using: 26641 26642 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 26643 26644 where NAME is the name of the attribute and VALUEI is the value 26645associated with MODEI. 26646 26647 When GCC replaces some :ITERATOR with :MODE, it will scan each string 26648and mode in the pattern for sequences of the form `<ITERATOR:ATTR>', 26649where ATTR is the name of a mode attribute. If the attribute is 26650defined for MODE, the whole `<...>' sequence will be replaced by the 26651appropriate attribute value. 26652 26653 For example, suppose an `.md' file has: 26654 26655 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 26656 (define_mode_attr load [(SI "lw") (DI "ld")]) 26657 26658 If one of the patterns that uses `:P' contains the string 26659`"<P:load>\t%0,%1"', the `SI' version of that pattern will use 26660`"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'. 26661 26662 Here is an example of using an attribute for a mode: 26663 26664 (define_mode_iterator LONG [SI DI]) 26665 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 26666 (define_insn ... 26667 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 26668 26669 The `ITERATOR:' prefix may be omitted, in which case the substitution 26670will be attempted for every iterator expansion. 26671 26672 26673File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 26674 2667516.23.1.3 Mode Iterator Examples 26676................................ 26677 26678Here is an example from the MIPS port. It defines the following modes 26679and attributes (among others): 26680 26681 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 26682 (define_mode_attr d [(SI "") (DI "d")]) 26683 26684 and uses the following template to define both `subsi3' and `subdi3': 26685 26686 (define_insn "sub<mode>3" 26687 [(set (match_operand:GPR 0 "register_operand" "=d") 26688 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 26689 (match_operand:GPR 2 "register_operand" "d")))] 26690 "" 26691 "<d>subu\t%0,%1,%2" 26692 [(set_attr "type" "arith") 26693 (set_attr "mode" "<MODE>")]) 26694 26695 This is exactly equivalent to: 26696 26697 (define_insn "subsi3" 26698 [(set (match_operand:SI 0 "register_operand" "=d") 26699 (minus:SI (match_operand:SI 1 "register_operand" "d") 26700 (match_operand:SI 2 "register_operand" "d")))] 26701 "" 26702 "subu\t%0,%1,%2" 26703 [(set_attr "type" "arith") 26704 (set_attr "mode" "SI")]) 26705 26706 (define_insn "subdi3" 26707 [(set (match_operand:DI 0 "register_operand" "=d") 26708 (minus:DI (match_operand:DI 1 "register_operand" "d") 26709 (match_operand:DI 2 "register_operand" "d")))] 26710 "" 26711 "dsubu\t%0,%1,%2" 26712 [(set_attr "type" "arith") 26713 (set_attr "mode" "DI")]) 26714 26715 26716File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 26717 2671816.23.2 Code Iterators 26719---------------------- 26720 26721Code iterators operate in a similar way to mode iterators. *Note Mode 26722Iterators::. 26723 26724 The construct: 26725 26726 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 26727 26728 defines a pseudo rtx code NAME that can be instantiated as CODEI if 26729condition CONDI is true. Each CODEI must have the same rtx format. 26730*Note RTL Classes::. 26731 26732 As with mode iterators, each pattern that uses NAME will be expanded N 26733times, once with all uses of NAME replaced by CODE1, once with all uses 26734replaced by CODE2, and so on. *Note Defining Mode Iterators::. 26735 26736 It is possible to define attributes for codes as well as for modes. 26737There are two standard code attributes: `code', the name of the code in 26738lower case, and `CODE', the name of the code in upper case. Other 26739attributes are defined using: 26740 26741 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 26742 26743 Here's an example of code iterators in action, taken from the MIPS 26744port: 26745 26746 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 26747 eq ne gt ge lt le gtu geu ltu leu]) 26748 26749 (define_expand "b<code>" 26750 [(set (pc) 26751 (if_then_else (any_cond:CC (cc0) 26752 (const_int 0)) 26753 (label_ref (match_operand 0 "")) 26754 (pc)))] 26755 "" 26756 { 26757 gen_conditional_branch (operands, <CODE>); 26758 DONE; 26759 }) 26760 26761 This is equivalent to: 26762 26763 (define_expand "bunordered" 26764 [(set (pc) 26765 (if_then_else (unordered:CC (cc0) 26766 (const_int 0)) 26767 (label_ref (match_operand 0 "")) 26768 (pc)))] 26769 "" 26770 { 26771 gen_conditional_branch (operands, UNORDERED); 26772 DONE; 26773 }) 26774 26775 (define_expand "bordered" 26776 [(set (pc) 26777 (if_then_else (ordered:CC (cc0) 26778 (const_int 0)) 26779 (label_ref (match_operand 0 "")) 26780 (pc)))] 26781 "" 26782 { 26783 gen_conditional_branch (operands, ORDERED); 26784 DONE; 26785 }) 26786 26787 ... 26788 26789 26790File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 26791 2679216.23.3 Int Iterators 26793--------------------- 26794 26795Int iterators operate in a similar way to code iterators. *Note Code 26796Iterators::. 26797 26798 The construct: 26799 26800 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 26801 26802 defines a pseudo integer constant NAME that can be instantiated as 26803INTI if condition CONDI is true. Each INT must have the same rtx 26804format. *Note RTL Classes::. Int iterators can appear in only those 26805rtx fields that have 'i' as the specifier. This means that each INT has 26806to be a constant defined using define_constant or define_c_enum. 26807 26808 As with mode and code iterators, each pattern that uses NAME will be 26809expanded N times, once with all uses of NAME replaced by INT1, once 26810with all uses replaced by INT2, and so on. *Note Defining Mode 26811Iterators::. 26812 26813 It is possible to define attributes for ints as well as for codes and 26814modes. Attributes are defined using: 26815 26816 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 26817 26818 Here's an example of int iterators in action, taken from the ARM port: 26819 26820 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 26821 26822 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 26823 26824 (define_insn "neon_vq<absneg><mode>" 26825 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 26826 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 26827 (match_operand:SI 2 "immediate_operand" "i")] 26828 QABSNEG))] 26829 "TARGET_NEON" 26830 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 26831 [(set_attr "neon_type" "neon_vqneg_vqabs")] 26832 ) 26833 26834 This is equivalent to: 26835 26836 (define_insn "neon_vqabs<mode>" 26837 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 26838 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 26839 (match_operand:SI 2 "immediate_operand" "i")] 26840 UNSPEC_VQABS))] 26841 "TARGET_NEON" 26842 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 26843 [(set_attr "neon_type" "neon_vqneg_vqabs")] 26844 ) 26845 26846 (define_insn "neon_vqneg<mode>" 26847 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 26848 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 26849 (match_operand:SI 2 "immediate_operand" "i")] 26850 UNSPEC_VQNEG))] 26851 "TARGET_NEON" 26852 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 26853 [(set_attr "neon_type" "neon_vqneg_vqabs")] 26854 ) 26855 26856 26857File: gccint.info, Node: Subst Iterators, Prev: Int Iterators, Up: Iterators 26858 2685916.23.4 Subst Iterators 26860----------------------- 26861 26862Subst iterators are special type of iterators with the following 26863restrictions: they could not be declared explicitly, they always have 26864only two values, and they do not have explicit dedicated name. 26865Subst-iterators are triggered only when corresponding subst-attribute is 26866used in RTL-pattern. 26867 26868 Subst iterators transform templates in the following way: the templates 26869are duplicated, the subst-attributes in these templates are replaced 26870with the corresponding values, and a new attribute is implicitly added 26871to the given `define_insn'/`define_expand'. The name of the added 26872attribute matches the name of `define_subst'. Such attributes are 26873declared implicitly, and it is not allowed to have a `define_attr' 26874named as a `define_subst'. 26875 26876 Each subst iterator is linked to a `define_subst'. It is declared 26877implicitly by the first appearance of the corresponding 26878`define_subst_attr', and it is not allowed to define it explicitly. 26879 26880 Declarations of subst-attributes have the following syntax: 26881 26882 (define_subst_attr "NAME" 26883 "SUBST-NAME" 26884 "NO-SUBST-VALUE" 26885 "SUBST-APPLIED-VALUE") 26886 26887 NAME is a string with which the given subst-attribute could be 26888referred to. 26889 26890 SUBST-NAME shows which `define_subst' should be applied to an 26891RTL-template if the given subst-attribute is present in the 26892RTL-template. 26893 26894 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 26895in the first copy of the original RTL-template. 26896 26897 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 26898replaced in the second copy of the original RTL-template. 26899 26900 26901File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 26902 2690317 Target Description Macros and Functions 26904****************************************** 26905 26906In addition to the file `MACHINE.md', a machine description includes a 26907C header file conventionally given the name `MACHINE.h' and a C source 26908file named `MACHINE.c'. The header file defines numerous macros that 26909convey the information about the target machine that does not fit into 26910the scheme of the `.md' file. The file `tm.h' should be a link to 26911`MACHINE.h'. The header file `config.h' includes `tm.h' and most 26912compiler source files include `config.h'. The source file defines a 26913variable `targetm', which is a structure containing pointers to 26914functions and data relating to the target machine. `MACHINE.c' should 26915also contain their definitions, if they are not defined elsewhere in 26916GCC, and other functions called through the macros defined in the `.h' 26917file. 26918 26919* Menu: 26920 26921* Target Structure:: The `targetm' variable. 26922* Driver:: Controlling how the driver runs the compilation passes. 26923* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 26924* Per-Function Data:: Defining data structures for per-function information. 26925* Storage Layout:: Defining sizes and alignments of data. 26926* Type Layout:: Defining sizes and properties of basic user data types. 26927* Registers:: Naming and describing the hardware registers. 26928* Register Classes:: Defining the classes of hardware registers. 26929* Old Constraints:: The old way to define machine-specific constraints. 26930* Stack and Calling:: Defining which way the stack grows and by how much. 26931* Varargs:: Defining the varargs macros. 26932* Trampolines:: Code set up at run time to enter a nested function. 26933* Library Calls:: Controlling how library routines are implicitly called. 26934* Addressing Modes:: Defining addressing modes valid for memory operands. 26935* Anchored Addresses:: Defining how `-fsection-anchors' should work. 26936* Condition Code:: Defining how insns update the condition code. 26937* Costs:: Defining relative costs of different operations. 26938* Scheduling:: Adjusting the behavior of the instruction scheduler. 26939* Sections:: Dividing storage into text, data, and other sections. 26940* PIC:: Macros for position independent code. 26941* Assembler Format:: Defining how to write insns and pseudo-ops to output. 26942* Debugging Info:: Defining the format of debugging output. 26943* Floating Point:: Handling floating point for cross-compilers. 26944* Mode Switching:: Insertion of mode-switching instructions. 26945* Target Attributes:: Defining target-specific uses of `__attribute__'. 26946* Emulated TLS:: Emulated TLS support. 26947* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 26948* PCH Target:: Validity checking for precompiled headers. 26949* C++ ABI:: Controlling C++ ABI changes. 26950* Named Address Spaces:: Adding support for named address spaces 26951* Misc:: Everything else. 26952 26953 26954File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 26955 2695617.1 The Global `targetm' Variable 26957================================== 26958 26959 -- Variable: struct gcc_target targetm 26960 The target `.c' file must define the global `targetm' variable 26961 which contains pointers to functions and data relating to the 26962 target machine. The variable is declared in `target.h'; 26963 `target-def.h' defines the macro `TARGET_INITIALIZER' which is 26964 used to initialize the variable, and macros for the default 26965 initializers for elements of the structure. The `.c' file should 26966 override those macros for which the default definition is 26967 inappropriate. For example: 26968 #include "target.h" 26969 #include "target-def.h" 26970 26971 /* Initialize the GCC target structure. */ 26972 26973 #undef TARGET_COMP_TYPE_ATTRIBUTES 26974 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 26975 26976 struct gcc_target targetm = TARGET_INITIALIZER; 26977 26978Where a macro should be defined in the `.c' file in this manner to form 26979part of the `targetm' structure, it is documented below as a "Target 26980Hook" with a prototype. Many macros will change in future from being 26981defined in the `.h' file to being part of the `targetm' structure. 26982 26983 Similarly, there is a `targetcm' variable for hooks that are specific 26984to front ends for C-family languages, documented as "C Target Hook". 26985This is declared in `c-family/c-target.h', the initializer 26986`TARGETCM_INITIALIZER' in `c-family/c-target-def.h'. If targets 26987initialize `targetcm' themselves, they should set 26988`target_has_targetcm=yes' in `config.gcc'; otherwise a default 26989definition is used. 26990 26991 Similarly, there is a `targetm_common' variable for hooks that are 26992shared between the compiler driver and the compilers proper, documented 26993as "Common Target Hook". This is declared in `common/common-target.h', 26994the initializer `TARGETM_COMMON_INITIALIZER' in 26995`common/common-target-def.h'. If targets initialize `targetm_common' 26996themselves, they should set `target_has_targetm_common=yes' in 26997`config.gcc'; otherwise a default definition is used. 26998 26999 27000File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 27001 2700217.2 Controlling the Compilation Driver, `gcc' 27003============================================== 27004 27005You can control the compilation driver. 27006 27007 -- Macro: DRIVER_SELF_SPECS 27008 A list of specs for the driver itself. It should be a suitable 27009 initializer for an array of strings, with no surrounding braces. 27010 27011 The driver applies these specs to its own command line between 27012 loading default `specs' files (but not command-line specified 27013 ones) and choosing the multilib directory or running any 27014 subcommands. It applies them in the order given, so each spec can 27015 depend on the options added by earlier ones. It is also possible 27016 to remove options using `%<OPTION' in the usual way. 27017 27018 This macro can be useful when a port has several interdependent 27019 target options. It provides a way of standardizing the command 27020 line so that the other specs are easier to write. 27021 27022 Do not define this macro if it does not need to do anything. 27023 27024 -- Macro: OPTION_DEFAULT_SPECS 27025 A list of specs used to support configure-time default options 27026 (i.e. `--with' options) in the driver. It should be a suitable 27027 initializer for an array of structures, each containing two 27028 strings, without the outermost pair of surrounding braces. 27029 27030 The first item in the pair is the name of the default. This must 27031 match the code in `config.gcc' for the target. The second item is 27032 a spec to apply if a default with this name was specified. The 27033 string `%(VALUE)' in the spec will be replaced by the value of the 27034 default everywhere it occurs. 27035 27036 The driver will apply these specs to its own command line between 27037 loading default `specs' files and processing `DRIVER_SELF_SPECS', 27038 using the same mechanism as `DRIVER_SELF_SPECS'. 27039 27040 Do not define this macro if it does not need to do anything. 27041 27042 -- Macro: CPP_SPEC 27043 A C string constant that tells the GCC driver program options to 27044 pass to CPP. It can also specify how to translate options you 27045 give to GCC into options for GCC to pass to the CPP. 27046 27047 Do not define this macro if it does not need to do anything. 27048 27049 -- Macro: CPLUSPLUS_CPP_SPEC 27050 This macro is just like `CPP_SPEC', but is used for C++, rather 27051 than C. If you do not define this macro, then the value of 27052 `CPP_SPEC' (if any) will be used instead. 27053 27054 -- Macro: CC1_SPEC 27055 A C string constant that tells the GCC driver program options to 27056 pass to `cc1', `cc1plus', `f771', and the other language front 27057 ends. It can also specify how to translate options you give to 27058 GCC into options for GCC to pass to front ends. 27059 27060 Do not define this macro if it does not need to do anything. 27061 27062 -- Macro: CC1PLUS_SPEC 27063 A C string constant that tells the GCC driver program options to 27064 pass to `cc1plus'. It can also specify how to translate options 27065 you give to GCC into options for GCC to pass to the `cc1plus'. 27066 27067 Do not define this macro if it does not need to do anything. Note 27068 that everything defined in CC1_SPEC is already passed to `cc1plus' 27069 so there is no need to duplicate the contents of CC1_SPEC in 27070 CC1PLUS_SPEC. 27071 27072 -- Macro: ASM_SPEC 27073 A C string constant that tells the GCC driver program options to 27074 pass to the assembler. It can also specify how to translate 27075 options you give to GCC into options for GCC to pass to the 27076 assembler. See the file `sun3.h' for an example of this. 27077 27078 Do not define this macro if it does not need to do anything. 27079 27080 -- Macro: ASM_FINAL_SPEC 27081 A C string constant that tells the GCC driver program how to run 27082 any programs which cleanup after the normal assembler. Normally, 27083 this is not needed. See the file `mips.h' for an example of this. 27084 27085 Do not define this macro if it does not need to do anything. 27086 27087 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 27088 Define this macro, with no value, if the driver should give the 27089 assembler an argument consisting of a single dash, `-', to 27090 instruct it to read from its standard input (which will be a pipe 27091 connected to the output of the compiler proper). This argument is 27092 given after any `-o' option specifying the name of the output file. 27093 27094 If you do not define this macro, the assembler is assumed to read 27095 its standard input if given no non-option arguments. If your 27096 assembler cannot read standard input at all, use a `%{pipe:%e}' 27097 construct; see `mips.h' for instance. 27098 27099 -- Macro: LINK_SPEC 27100 A C string constant that tells the GCC driver program options to 27101 pass to the linker. It can also specify how to translate options 27102 you give to GCC into options for GCC to pass to the linker. 27103 27104 Do not define this macro if it does not need to do anything. 27105 27106 -- Macro: LIB_SPEC 27107 Another C string constant used much like `LINK_SPEC'. The 27108 difference between the two is that `LIB_SPEC' is used at the end 27109 of the command given to the linker. 27110 27111 If this macro is not defined, a default is provided that loads the 27112 standard C library from the usual place. See `gcc.c'. 27113 27114 -- Macro: LIBGCC_SPEC 27115 Another C string constant that tells the GCC driver program how 27116 and when to place a reference to `libgcc.a' into the linker 27117 command line. This constant is placed both before and after the 27118 value of `LIB_SPEC'. 27119 27120 If this macro is not defined, the GCC driver provides a default 27121 that passes the string `-lgcc' to the linker. 27122 27123 -- Macro: REAL_LIBGCC_SPEC 27124 By default, if `ENABLE_SHARED_LIBGCC' is defined, the 27125 `LIBGCC_SPEC' is not directly used by the driver program but is 27126 instead modified to refer to different versions of `libgcc.a' 27127 depending on the values of the command line flags `-static', 27128 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets 27129 where these modifications are inappropriate, define 27130 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver 27131 how to place a reference to `libgcc' on the link command line, 27132 but, unlike `LIBGCC_SPEC', it is used unmodified. 27133 27134 -- Macro: USE_LD_AS_NEEDED 27135 A macro that controls the modifications to `LIBGCC_SPEC' mentioned 27136 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 27137 uses -as-needed and the shared libgcc in place of the static 27138 exception handler library, when linking without any of `-static', 27139 `-static-libgcc', or `-shared-libgcc'. 27140 27141 -- Macro: LINK_EH_SPEC 27142 If defined, this C string constant is added to `LINK_SPEC'. When 27143 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the 27144 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'. 27145 27146 -- Macro: STARTFILE_SPEC 27147 Another C string constant used much like `LINK_SPEC'. The 27148 difference between the two is that `STARTFILE_SPEC' is used at the 27149 very beginning of the command given to the linker. 27150 27151 If this macro is not defined, a default is provided that loads the 27152 standard C startup file from the usual place. See `gcc.c'. 27153 27154 -- Macro: ENDFILE_SPEC 27155 Another C string constant used much like `LINK_SPEC'. The 27156 difference between the two is that `ENDFILE_SPEC' is used at the 27157 very end of the command given to the linker. 27158 27159 Do not define this macro if it does not need to do anything. 27160 27161 -- Macro: THREAD_MODEL_SPEC 27162 GCC `-v' will print the thread model GCC was configured to use. 27163 However, this doesn't work on platforms that are multilibbed on 27164 thread models, such as AIX 4.3. On such platforms, define 27165 `THREAD_MODEL_SPEC' such that it evaluates to a string without 27166 blanks that names one of the recognized thread models. `%*', the 27167 default value of this macro, will expand to the value of 27168 `thread_file' set in `config.gcc'. 27169 27170 -- Macro: SYSROOT_SUFFIX_SPEC 27171 Define this macro to add a suffix to the target sysroot when GCC is 27172 configured with a sysroot. This will cause GCC to search for 27173 usr/lib, et al, within sysroot+suffix. 27174 27175 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 27176 Define this macro to add a headers_suffix to the target sysroot 27177 when GCC is configured with a sysroot. This will cause GCC to 27178 pass the updated sysroot+headers_suffix to CPP, causing it to 27179 search for usr/include, et al, within sysroot+headers_suffix. 27180 27181 -- Macro: EXTRA_SPECS 27182 Define this macro to provide additional specifications to put in 27183 the `specs' file that can be used in various specifications like 27184 `CC1_SPEC'. 27185 27186 The definition should be an initializer for an array of structures, 27187 containing a string constant, that defines the specification name, 27188 and a string constant that provides the specification. 27189 27190 Do not define this macro if it does not need to do anything. 27191 27192 `EXTRA_SPECS' is useful when an architecture contains several 27193 related targets, which have various `..._SPECS' which are similar 27194 to each other, and the maintainer would like one central place to 27195 keep these definitions. 27196 27197 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to 27198 define either `_CALL_SYSV' when the System V calling sequence is 27199 used or `_CALL_AIX' when the older AIX-based calling sequence is 27200 used. 27201 27202 The `config/rs6000/rs6000.h' target file defines: 27203 27204 #define EXTRA_SPECS \ 27205 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 27206 27207 #define CPP_SYS_DEFAULT "" 27208 27209 The `config/rs6000/sysv.h' target file defines: 27210 #undef CPP_SPEC 27211 #define CPP_SPEC \ 27212 "%{posix: -D_POSIX_SOURCE } \ 27213 %{mcall-sysv: -D_CALL_SYSV } \ 27214 %{!mcall-sysv: %(cpp_sysv_default) } \ 27215 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 27216 27217 #undef CPP_SYSV_DEFAULT 27218 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 27219 27220 while the `config/rs6000/eabiaix.h' target file defines 27221 `CPP_SYSV_DEFAULT' as: 27222 27223 #undef CPP_SYSV_DEFAULT 27224 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 27225 27226 -- Macro: LINK_LIBGCC_SPECIAL_1 27227 Define this macro if the driver program should find the library 27228 `libgcc.a'. If you do not define this macro, the driver program 27229 will pass the argument `-lgcc' to tell the linker to do the search. 27230 27231 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 27232 The sequence in which libgcc and libc are specified to the linker. 27233 By default this is `%G %L %G'. 27234 27235 -- Macro: LINK_COMMAND_SPEC 27236 A C string constant giving the complete command line need to 27237 execute the linker. When you do this, you will need to update 27238 your port each time a change is made to the link command line 27239 within `gcc.c'. Therefore, define this macro only if you need to 27240 completely redefine the command line for invoking the linker and 27241 there is no other way to accomplish the effect you need. 27242 Overriding this macro may be avoidable by overriding 27243 `LINK_GCC_C_SEQUENCE_SPEC' instead. 27244 27245 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 27246 True if `..' components should always be removed from directory 27247 names computed relative to GCC's internal directories, false 27248 (default) if such components should be preserved and directory 27249 names containing them passed to other tools such as the linker. 27250 27251 -- Macro: MULTILIB_DEFAULTS 27252 Define this macro as a C expression for the initializer of an 27253 array of string to tell the driver program which options are 27254 defaults for this target and thus do not need to be handled 27255 specially when using `MULTILIB_OPTIONS'. 27256 27257 Do not define this macro if `MULTILIB_OPTIONS' is not defined in 27258 the target makefile fragment or if none of the options listed in 27259 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 27260 27261 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 27262 Define this macro to tell `gcc' that it should only translate a 27263 `-B' prefix into a `-L' linker option if the prefix indicates an 27264 absolute file name. 27265 27266 -- Macro: MD_EXEC_PREFIX 27267 If defined, this macro is an additional prefix to try after 27268 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the 27269 compiler is built as a cross compiler. If you define 27270 `MD_EXEC_PREFIX', then be sure to add it to the list of 27271 directories used to find the assembler in `configure.in'. 27272 27273 -- Macro: STANDARD_STARTFILE_PREFIX 27274 Define this macro as a C string constant if you wish to override 27275 the standard choice of `libdir' as the default prefix to try when 27276 searching for startup files such as `crt0.o'. 27277 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 27278 built as a cross compiler. 27279 27280 -- Macro: STANDARD_STARTFILE_PREFIX_1 27281 Define this macro as a C string constant if you wish to override 27282 the standard choice of `/lib' as a prefix to try after the default 27283 prefix when searching for startup files such as `crt0.o'. 27284 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 27285 built as a cross compiler. 27286 27287 -- Macro: STANDARD_STARTFILE_PREFIX_2 27288 Define this macro as a C string constant if you wish to override 27289 the standard choice of `/lib' as yet another prefix to try after 27290 the default prefix when searching for startup files such as 27291 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the 27292 compiler is built as a cross compiler. 27293 27294 -- Macro: MD_STARTFILE_PREFIX 27295 If defined, this macro supplies an additional prefix to try after 27296 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the 27297 compiler is built as a cross compiler. 27298 27299 -- Macro: MD_STARTFILE_PREFIX_1 27300 If defined, this macro supplies yet another prefix to try after the 27301 standard prefixes. It is not searched when the compiler is built 27302 as a cross compiler. 27303 27304 -- Macro: INIT_ENVIRONMENT 27305 Define this macro as a C string constant if you wish to set 27306 environment variables for programs called by the driver, such as 27307 the assembler and loader. The driver passes the value of this 27308 macro to `putenv' to initialize the necessary environment 27309 variables. 27310 27311 -- Macro: LOCAL_INCLUDE_DIR 27312 Define this macro as a C string constant if you wish to override 27313 the standard choice of `/usr/local/include' as the default prefix 27314 to try when searching for local header files. `LOCAL_INCLUDE_DIR' 27315 comes before `NATIVE_SYSTEM_HEADER_DIR' (set in `config.gcc', 27316 normally `/usr/include') in the search order. 27317 27318 Cross compilers do not search either `/usr/local/include' or its 27319 replacement. 27320 27321 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 27322 The "component" corresponding to `NATIVE_SYSTEM_HEADER_DIR'. See 27323 `INCLUDE_DEFAULTS', below, for the description of components. If 27324 you do not define this macro, no component is used. 27325 27326 -- Macro: INCLUDE_DEFAULTS 27327 Define this macro if you wish to override the entire default 27328 search path for include files. For a native compiler, the default 27329 search path usually consists of `GCC_INCLUDE_DIR', 27330 `LOCAL_INCLUDE_DIR', `GPLUSPLUS_INCLUDE_DIR', and 27331 `NATIVE_SYSTEM_HEADER_DIR'. In addition, `GPLUSPLUS_INCLUDE_DIR' 27332 and `GCC_INCLUDE_DIR' are defined automatically by `Makefile', and 27333 specify private search areas for GCC. The directory 27334 `GPLUSPLUS_INCLUDE_DIR' is used only for C++ programs. 27335 27336 The definition should be an initializer for an array of structures. 27337 Each array element should have four elements: the directory name (a 27338 string constant), the component name (also a string constant), a 27339 flag for C++-only directories, and a flag showing that the 27340 includes in the directory don't need to be wrapped in `extern `C'' 27341 when compiling C++. Mark the end of the array with a null element. 27342 27343 The component name denotes what GNU package the include file is 27344 part of, if any, in all uppercase letters. For example, it might 27345 be `GCC' or `BINUTILS'. If the package is part of a 27346 vendor-supplied operating system, code the component name as `0'. 27347 27348 For example, here is the definition used for VAX/VMS: 27349 27350 #define INCLUDE_DEFAULTS \ 27351 { \ 27352 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 27353 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 27354 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 27355 { ".", 0, 0, 0}, \ 27356 { 0, 0, 0, 0} \ 27357 } 27358 27359 Here is the order of prefixes tried for exec files: 27360 27361 1. Any prefixes specified by the user with `-B'. 27362 27363 2. The environment variable `GCC_EXEC_PREFIX' or, if `GCC_EXEC_PREFIX' 27364 is not set and the compiler has not been installed in the 27365 configure-time PREFIX, the location in which the compiler has 27366 actually been installed. 27367 27368 3. The directories specified by the environment variable 27369 `COMPILER_PATH'. 27370 27371 4. The macro `STANDARD_EXEC_PREFIX', if the compiler has been 27372 installed in the configured-time PREFIX. 27373 27374 5. The location `/usr/libexec/gcc/', but only if this is a native 27375 compiler. 27376 27377 6. The location `/usr/lib/gcc/', but only if this is a native 27378 compiler. 27379 27380 7. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 27381 native compiler. 27382 27383 Here is the order of prefixes tried for startfiles: 27384 27385 1. Any prefixes specified by the user with `-B'. 27386 27387 2. The environment variable `GCC_EXEC_PREFIX' or its automatically 27388 determined value based on the installed toolchain location. 27389 27390 3. The directories specified by the environment variable 27391 `LIBRARY_PATH' (or port-specific name; native only, cross 27392 compilers do not use this). 27393 27394 4. The macro `STANDARD_EXEC_PREFIX', but only if the toolchain is 27395 installed in the configured PREFIX or this is a native compiler. 27396 27397 5. The location `/usr/lib/gcc/', but only if this is a native 27398 compiler. 27399 27400 6. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 27401 native compiler. 27402 27403 7. The macro `MD_STARTFILE_PREFIX', if defined, but only if this is a 27404 native compiler, or we have a target system root. 27405 27406 8. The macro `MD_STARTFILE_PREFIX_1', if defined, but only if this is 27407 a native compiler, or we have a target system root. 27408 27409 9. The macro `STANDARD_STARTFILE_PREFIX', with any sysroot 27410 modifications. If this path is relative it will be prefixed by 27411 `GCC_EXEC_PREFIX' and the machine suffix or `STANDARD_EXEC_PREFIX' 27412 and the machine suffix. 27413 27414 10. The macro `STANDARD_STARTFILE_PREFIX_1', but only if this is a 27415 native compiler, or we have a target system root. The default for 27416 this macro is `/lib/'. 27417 27418 11. The macro `STANDARD_STARTFILE_PREFIX_2', but only if this is a 27419 native compiler, or we have a target system root. The default for 27420 this macro is `/usr/lib/'. 27421 27422 27423File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 27424 2742517.3 Run-time Target Specification 27426================================== 27427 27428Here are run-time target specifications. 27429 27430 -- Macro: TARGET_CPU_CPP_BUILTINS () 27431 This function-like macro expands to a block of code that defines 27432 built-in preprocessor macros and assertions for the target CPU, 27433 using the functions `builtin_define', `builtin_define_std' and 27434 `builtin_assert'. When the front end calls this macro it provides 27435 a trailing semicolon, and since it has finished command line 27436 option processing your code can use those results freely. 27437 27438 `builtin_assert' takes a string in the form you pass to the 27439 command-line option `-A', such as `cpu=mips', and creates the 27440 assertion. `builtin_define' takes a string in the form accepted 27441 by option `-D' and unconditionally defines the macro. 27442 27443 `builtin_define_std' takes a string representing the name of an 27444 object-like macro. If it doesn't lie in the user's namespace, 27445 `builtin_define_std' defines it unconditionally. Otherwise, it 27446 defines a version with two leading underscores, and another version 27447 with two leading and trailing underscores, and defines the original 27448 only if an ISO standard was not requested on the command line. For 27449 example, passing `unix' defines `__unix', `__unix__' and possibly 27450 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly 27451 `_mips', and passing `_ABI64' defines only `_ABI64'. 27452 27453 You can also test for the C dialect being compiled. The variable 27454 `c_language' is set to one of `clk_c', `clk_cplusplus' or 27455 `clk_objective_c'. Note that if we are preprocessing assembler, 27456 this variable will be `clk_c' but the function-like macro 27457 `preprocessing_asm_p()' will return true, so you might want to 27458 check for that first. If you need to check for strict ANSI, the 27459 variable `flag_iso' can be used. The function-like macro 27460 `preprocessing_trad_p()' can be used to check for traditional 27461 preprocessing. 27462 27463 -- Macro: TARGET_OS_CPP_BUILTINS () 27464 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 27465 and is used for the target operating system instead. 27466 27467 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 27468 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 27469 and is used for the target object format. `elfos.h' uses this 27470 macro to define `__ELF__', so you probably do not need to define 27471 it yourself. 27472 27473 -- Variable: extern int target_flags 27474 This variable is declared in `options.h', which is included before 27475 any target-specific headers. 27476 27477 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 27478 This variable specifies the initial value of `target_flags'. Its 27479 default setting is 0. 27480 27481 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 27482 *OPTS, struct gcc_options *OPTS_SET, const struct 27483 cl_decoded_option *DECODED, location_t LOC) 27484 This hook is called whenever the user specifies one of the 27485 target-specific options described by the `.opt' definition files 27486 (*note Options::). It has the opportunity to do some 27487 option-specific processing and should return true if the option is 27488 valid. The default definition does nothing but return true. 27489 27490 DECODED specifies the option and its arguments. OPTS and OPTS_SET 27491 are the `gcc_options' structures to be used for storing option 27492 state, and LOC is the location at which the option was passed 27493 (`UNKNOWN_LOCATION' except for options passed via attributes). 27494 27495 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 27496 *ARG, int VALUE) 27497 This target hook is called whenever the user specifies one of the 27498 target-specific C language family options described by the `.opt' 27499 definition files(*note Options::). It has the opportunity to do 27500 some option-specific processing and should return true if the 27501 option is valid. The arguments are like for 27502 `TARGET_HANDLE_OPTION'. The default definition does nothing but 27503 return false. 27504 27505 In general, you should use `TARGET_HANDLE_OPTION' to handle 27506 options. However, if processing an option requires routines that 27507 are only available in the C (and related language) front ends, 27508 then you should use `TARGET_HANDLE_C_OPTION' instead. 27509 27510 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 27511 STRING) 27512 Targets may provide a string object type that can be used within 27513 and between C, C++ and their respective Objective-C dialects. A 27514 string object might, for example, embed encoding and length 27515 information. These objects are considered opaque to the compiler 27516 and handled as references. An ideal implementation makes the 27517 composition of the string object match that of the Objective-C 27518 `NSString' (`NXString' for GNUStep), allowing efficient 27519 interworking between C-only and Objective-C code. If a target 27520 implements string objects then this hook should return a reference 27521 to such an object constructed from the normal `C' string 27522 representation provided in STRING. At present, the hook is used by 27523 Objective-C only, to obtain a common-format string object when the 27524 target provides one. 27525 27526 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 27527 (const char *CLASSNAME) 27528 Declare that Objective C class CLASSNAME is referenced by the 27529 current TU. 27530 27531 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const 27532 char *CLASSNAME) 27533 Declare that Objective C class CLASSNAME is defined by the 27534 current TU. 27535 27536 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 27537 STRINGREF) 27538 If a target implements string objects then this hook should return 27539 `true' if STRINGREF is a valid reference to such an object. 27540 27541 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 27542 FORMAT_ARG, tree ARGS_LIST) 27543 If a target implements string objects then this hook should should 27544 provide a facility to check the function arguments in ARGS_LIST 27545 against the format specifiers in FORMAT_ARG where the type of 27546 FORMAT_ARG is one recognized as a valid string reference type. 27547 27548 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 27549 This target function is similar to the hook 27550 `TARGET_OPTION_OVERRIDE' but is called when the optimize level is 27551 changed via an attribute or pragma or when it is reset at the end 27552 of the code affected by the attribute or pragma. It is not called 27553 at the beginning of compilation when `TARGET_OPTION_OVERRIDE' is 27554 called so if you want to perform these actions then, you should 27555 have `TARGET_OPTION_OVERRIDE' call 27556 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 27557 27558 -- Macro: C_COMMON_OVERRIDE_OPTIONS 27559 This is similar to the `TARGET_OPTION_OVERRIDE' hook but is only 27560 used in the C language frontends (C, Objective-C, C++, 27561 Objective-C++) and so can be used to alter option flag variables 27562 which only exist in those frontends. 27563 27564 -- Common Target Hook: const struct default_options * 27565TARGET_OPTION_OPTIMIZATION_TABLE 27566 Some machines may desire to change what optimizations are 27567 performed for various optimization levels. This variable, if 27568 defined, describes options to enable at particular sets of 27569 optimization levels. These options are processed once just after 27570 the optimization level is determined and before the remainder of 27571 the command options have been parsed, so may be overridden by other 27572 options passed explicitly. 27573 27574 This processing is run once at program startup and when the 27575 optimization options are changed via `#pragma GCC optimize' or by 27576 using the `optimize' attribute. 27577 27578 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 27579 gcc_options *OPTS) 27580 Set target-dependent initial values of fields in OPTS. 27581 27582 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 27583 Set target-dependent default values for `--param' settings, using 27584 calls to `set_default_param_value'. 27585 27586 -- Macro: SWITCHABLE_TARGET 27587 Some targets need to switch between substantially different 27588 subtargets during compilation. For example, the MIPS target has 27589 one subtarget for the traditional MIPS architecture and another 27590 for MIPS16. Source code can switch between these two 27591 subarchitectures using the `mips16' and `nomips16' attributes. 27592 27593 Such subtargets can differ in things like the set of available 27594 registers, the set of available instructions, the costs of various 27595 operations, and so on. GCC caches a lot of this type of 27596 information in global variables, and recomputing them for each 27597 subtarget takes a significant amount of time. The compiler 27598 therefore provides a facility for maintaining several versions of 27599 the global variables and quickly switching between them; see 27600 `target-globals.h' for details. 27601 27602 Define this macro to 1 if your target needs this facility. The 27603 default is 0. 27604 27605 27606File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 27607 2760817.4 Defining data structures for per-function information. 27609=========================================================== 27610 27611If the target needs to store information on a per-function basis, GCC 27612provides a macro and a couple of variables to allow this. Note, just 27613using statics to store the information is a bad idea, since GCC supports 27614nested functions, so you can be halfway through encoding one function 27615when another one comes along. 27616 27617 GCC defines a data structure called `struct function' which contains 27618all of the data specific to an individual function. This structure 27619contains a field called `machine' whose type is `struct 27620machine_function *', which can be used by targets to point to their own 27621specific data. 27622 27623 If a target needs per-function specific data it should define the type 27624`struct machine_function' and also the macro `INIT_EXPANDERS'. This 27625macro should be used to initialize the function pointer 27626`init_machine_status'. This pointer is explained below. 27627 27628 One typical use of per-function, target specific data is to create an 27629RTX to hold the register containing the function's return address. This 27630RTX can then be used to implement the `__builtin_return_address' 27631function, for level 0. 27632 27633 Note--earlier implementations of GCC used a single data area to hold 27634all of the per-function information. Thus when processing of a nested 27635function began the old per-function data had to be pushed onto a stack, 27636and when the processing was finished, it had to be popped off the 27637stack. GCC used to provide function pointers called 27638`save_machine_status' and `restore_machine_status' to handle the saving 27639and restoring of the target specific information. Since the single 27640data area approach is no longer used, these pointers are no longer 27641supported. 27642 27643 -- Macro: INIT_EXPANDERS 27644 Macro called to initialize any target specific information. This 27645 macro is called once per function, before generation of any RTL 27646 has begun. The intention of this macro is to allow the 27647 initialization of the function pointer `init_machine_status'. 27648 27649 -- Variable: void (*)(struct function *) init_machine_status 27650 If this function pointer is non-`NULL' it will be called once per 27651 function, before function compilation starts, in order to allow the 27652 target to perform any target specific initialization of the 27653 `struct function' structure. It is intended that this would be 27654 used to initialize the `machine' of that structure. 27655 27656 `struct machine_function' structures are expected to be freed by 27657 GC. Generally, any memory that they reference must be allocated 27658 by using GC allocation, including the structure itself. 27659 27660 27661File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 27662 2766317.5 Storage Layout 27664=================== 27665 27666Note that the definitions of the macros in this table which are sizes or 27667alignments measured in bits do not need to be constant. They can be C 27668expressions that refer to static variables, such as the `target_flags'. 27669*Note Run-time Target::. 27670 27671 -- Macro: BITS_BIG_ENDIAN 27672 Define this macro to have the value 1 if the most significant bit 27673 in a byte has the lowest number; otherwise define it to have the 27674 value zero. This means that bit-field instructions count from the 27675 most significant bit. If the machine has no bit-field 27676 instructions, then this must still be defined, but it doesn't 27677 matter which value it is defined to. This macro need not be a 27678 constant. 27679 27680 This macro does not affect the way structure fields are packed into 27681 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. 27682 27683 -- Macro: BYTES_BIG_ENDIAN 27684 Define this macro to have the value 1 if the most significant byte 27685 in a word has the lowest number. This macro need not be a 27686 constant. 27687 27688 -- Macro: WORDS_BIG_ENDIAN 27689 Define this macro to have the value 1 if, in a multiword object, 27690 the most significant word has the lowest number. This applies to 27691 both memory locations and registers; see `REG_WORDS_BIG_ENDIAN' if 27692 the order of words in memory is not the same as the order in 27693 registers. This macro need not be a constant. 27694 27695 -- Macro: REG_WORDS_BIG_ENDIAN 27696 On some machines, the order of words in a multiword object differs 27697 between registers in memory. In such a situation, define this 27698 macro to describe the order of words in a register. The macro 27699 `WORDS_BIG_ENDIAN' controls the order of words in memory. 27700 27701 -- Macro: FLOAT_WORDS_BIG_ENDIAN 27702 Define this macro to have the value 1 if `DFmode', `XFmode' or 27703 `TFmode' floating point numbers are stored in memory with the word 27704 containing the sign bit at the lowest address; otherwise define it 27705 to have the value 0. This macro need not be a constant. 27706 27707 You need not define this macro if the ordering is the same as for 27708 multi-word integers. 27709 27710 -- Macro: BITS_PER_UNIT 27711 Define this macro to be the number of bits in an addressable 27712 storage unit (byte). If you do not define this macro the default 27713 is 8. 27714 27715 -- Macro: BITS_PER_WORD 27716 Number of bits in a word. If you do not define this macro, the 27717 default is `BITS_PER_UNIT * UNITS_PER_WORD'. 27718 27719 -- Macro: MAX_BITS_PER_WORD 27720 Maximum number of bits in a word. If this is undefined, the 27721 default is `BITS_PER_WORD'. Otherwise, it is the constant value 27722 that is the largest value that `BITS_PER_WORD' can have at 27723 run-time. 27724 27725 -- Macro: UNITS_PER_WORD 27726 Number of storage units in a word; normally the size of a 27727 general-purpose register, a power of two from 1 or 8. 27728 27729 -- Macro: MIN_UNITS_PER_WORD 27730 Minimum number of units in a word. If this is undefined, the 27731 default is `UNITS_PER_WORD'. Otherwise, it is the constant value 27732 that is the smallest value that `UNITS_PER_WORD' can have at 27733 run-time. 27734 27735 -- Macro: POINTER_SIZE 27736 Width of a pointer, in bits. You must specify a value no wider 27737 than the width of `Pmode'. If it is not equal to the width of 27738 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do 27739 not specify a value the default is `BITS_PER_WORD'. 27740 27741 -- Macro: POINTERS_EXTEND_UNSIGNED 27742 A C expression that determines how pointers should be extended from 27743 `ptr_mode' to either `Pmode' or `word_mode'. It is greater than 27744 zero if pointers should be zero-extended, zero if they should be 27745 sign-extended, and negative if some other sort of conversion is 27746 needed. In the last case, the extension is done by the target's 27747 `ptr_extend' instruction. 27748 27749 You need not define this macro if the `ptr_mode', `Pmode' and 27750 `word_mode' are all the same width. 27751 27752 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 27753 A macro to update M and UNSIGNEDP when an object whose type is 27754 TYPE and which has the specified mode and signedness is to be 27755 stored in a register. This macro is only called when TYPE is a 27756 scalar type. 27757 27758 On most RISC machines, which only have operations that operate on 27759 a full register, define this macro to set M to `word_mode' if M is 27760 an integer mode narrower than `BITS_PER_WORD'. In most cases, 27761 only integer modes should be widened because wider-precision 27762 floating-point operations are usually more expensive than their 27763 narrower counterparts. 27764 27765 For most machines, the macro definition does not change UNSIGNEDP. 27766 However, some machines, have instructions that preferentially 27767 handle either signed or unsigned quantities of certain modes. For 27768 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 27769 instructions sign-extend the result to 64 bits. On such machines, 27770 set UNSIGNEDP according to which kind of extension is more 27771 efficient. 27772 27773 Do not define this macro if it would never modify M. 27774 27775 -- Target Hook: enum machine_mode TARGET_PROMOTE_FUNCTION_MODE 27776 (const_tree TYPE, enum machine_mode MODE, int *PUNSIGNEDP, 27777 const_tree FUNTYPE, int FOR_RETURN) 27778 Like `PROMOTE_MODE', but it is applied to outgoing function 27779 arguments or function return values. The target hook should 27780 return the new mode and possibly change `*PUNSIGNEDP' if the 27781 promotion should change signedness. This function is called only 27782 for scalar _or pointer_ types. 27783 27784 FOR_RETURN allows to distinguish the promotion of arguments and 27785 return values. If it is `1', a return value is being promoted and 27786 `TARGET_FUNCTION_VALUE' must perform the same promotions done here. 27787 If it is `2', the returned mode should be that of the register in 27788 which an incoming parameter is copied, or the outgoing result is 27789 computed; then the hook should return the same mode as 27790 `promote_mode', though the signedness may be different. 27791 27792 TYPE can be NULL when promoting function arguments of libcalls. 27793 27794 The default is to not promote arguments and return values. You can 27795 also define the hook to 27796 `default_promote_function_mode_always_promote' if you would like 27797 to apply the same rules given by `PROMOTE_MODE'. 27798 27799 -- Macro: PARM_BOUNDARY 27800 Normal alignment required for function parameters on the stack, in 27801 bits. All stack parameters receive at least this much alignment 27802 regardless of data type. On most machines, this is the same as the 27803 size of an integer. 27804 27805 -- Macro: STACK_BOUNDARY 27806 Define this macro to the minimum alignment enforced by hardware 27807 for the stack pointer on this machine. The definition is a C 27808 expression for the desired alignment (measured in bits). This 27809 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not 27810 defined. On most machines, this should be the same as 27811 `PARM_BOUNDARY'. 27812 27813 -- Macro: PREFERRED_STACK_BOUNDARY 27814 Define this macro if you wish to preserve a certain alignment for 27815 the stack pointer, greater than what the hardware enforces. The 27816 definition is a C expression for the desired alignment (measured 27817 in bits). This macro must evaluate to a value equal to or larger 27818 than `STACK_BOUNDARY'. 27819 27820 -- Macro: INCOMING_STACK_BOUNDARY 27821 Define this macro if the incoming stack boundary may be different 27822 from `PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 27823 value equal to or larger than `STACK_BOUNDARY'. 27824 27825 -- Macro: FUNCTION_BOUNDARY 27826 Alignment required for a function entry point, in bits. 27827 27828 -- Macro: BIGGEST_ALIGNMENT 27829 Biggest alignment that any data type can require on this machine, 27830 in bits. Note that this is not the biggest alignment that is 27831 supported, just the biggest alignment that, when violated, may 27832 cause a fault. 27833 27834 -- Macro: MALLOC_ABI_ALIGNMENT 27835 Alignment, in bits, a C conformant malloc implementation has to 27836 provide. If not defined, the default value is `BITS_PER_WORD'. 27837 27838 -- Macro: ATTRIBUTE_ALIGNED_VALUE 27839 Alignment used by the `__attribute__ ((aligned))' construct. If 27840 not defined, the default value is `BIGGEST_ALIGNMENT'. 27841 27842 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 27843 If defined, the smallest alignment, in bits, that can be given to 27844 an object that can be referenced in one operation, without 27845 disturbing any nearby object. Normally, this is `BITS_PER_UNIT', 27846 but may be larger on machines that don't have byte or half-word 27847 store operations. 27848 27849 -- Macro: BIGGEST_FIELD_ALIGNMENT 27850 Biggest alignment that any structure or union field can require on 27851 this machine, in bits. If defined, this overrides 27852 `BIGGEST_ALIGNMENT' for structure and union fields only, unless 27853 the field alignment has been set by the `__attribute__ ((aligned 27854 (N)))' construct. 27855 27856 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 27857 An expression for the alignment of a structure field FIELD if the 27858 alignment computed in the usual way (including applying of 27859 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the 27860 alignment) is COMPUTED. It overrides alignment only if the field 27861 alignment has not been set by the `__attribute__ ((aligned (N)))' 27862 construct. 27863 27864 -- Macro: MAX_STACK_ALIGNMENT 27865 Biggest stack alignment guaranteed by the backend. Use this macro 27866 to specify the maximum alignment of a variable on stack. 27867 27868 If not defined, the default value is `STACK_BOUNDARY'. 27869 27870 27871 -- Macro: MAX_OFILE_ALIGNMENT 27872 Biggest alignment supported by the object file format of this 27873 machine. Use this macro to limit the alignment which can be 27874 specified using the `__attribute__ ((aligned (N)))' construct. If 27875 not defined, the default value is `BIGGEST_ALIGNMENT'. 27876 27877 On systems that use ELF, the default (in `config/elfos.h') is the 27878 largest supported 32-bit ELF section alignment representable on a 27879 32-bit host e.g. `(((unsigned HOST_WIDEST_INT) 1 << 28) * 8)'. On 27880 32-bit ELF the largest supported section alignment in bits is 27881 `(0x80000000 * 8)', but this is not representable on 32-bit hosts. 27882 27883 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 27884 If defined, a C expression to compute the alignment for a variable 27885 in the static store. TYPE is the data type, and BASIC-ALIGN is 27886 the alignment that the object would ordinarily have. The value of 27887 this macro is used instead of that alignment to align the object. 27888 27889 If this macro is not defined, then BASIC-ALIGN is used. 27890 27891 One use of this macro is to increase alignment of medium-size data 27892 to make it all fit in fewer cache lines. Another is to cause 27893 character arrays to be word-aligned so that `strcpy' calls that 27894 copy constants to character arrays can be done inline. 27895 27896 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 27897 If defined, a C expression to compute the alignment given to a 27898 constant that is being placed in memory. CONSTANT is the constant 27899 and BASIC-ALIGN is the alignment that the object would ordinarily 27900 have. The value of this macro is used instead of that alignment to 27901 align the object. 27902 27903 If this macro is not defined, then BASIC-ALIGN is used. 27904 27905 The typical use of this macro is to increase alignment for string 27906 constants to be word aligned so that `strcpy' calls that copy 27907 constants can be done inline. 27908 27909 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 27910 If defined, a C expression to compute the alignment for a variable 27911 in the local store. TYPE is the data type, and BASIC-ALIGN is the 27912 alignment that the object would ordinarily have. The value of this 27913 macro is used instead of that alignment to align the object. 27914 27915 If this macro is not defined, then BASIC-ALIGN is used. 27916 27917 One use of this macro is to increase alignment of medium-size data 27918 to make it all fit in fewer cache lines. 27919 27920 If the value of this macro has a type, it should be an unsigned 27921 type. 27922 27923 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 27924 This hook can be used to define the alignment for a vector of type 27925 TYPE, in order to comply with a platform ABI. The default is to 27926 require natural alignment for vector types. The alignment 27927 returned by this hook must be a power-of-two multiple of the 27928 default alignment of the vector element type. 27929 27930 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 27931 If defined, a C expression to compute the alignment for stack slot. 27932 TYPE is the data type, MODE is the widest mode available, and 27933 BASIC-ALIGN is the alignment that the slot would ordinarily have. 27934 The value of this macro is used instead of that alignment to align 27935 the slot. 27936 27937 If this macro is not defined, then BASIC-ALIGN is used when TYPE 27938 is `NULL'. Otherwise, `LOCAL_ALIGNMENT' will be used. 27939 27940 This macro is to set alignment of stack slot to the maximum 27941 alignment of all possible modes which the slot may have. 27942 27943 If the value of this macro has a type, it should be an unsigned 27944 type. 27945 27946 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 27947 If defined, a C expression to compute the alignment for a local 27948 variable DECL. 27949 27950 If this macro is not defined, then `LOCAL_ALIGNMENT (TREE_TYPE 27951 (DECL), DECL_ALIGN (DECL))' is used. 27952 27953 One use of this macro is to increase alignment of medium-size data 27954 to make it all fit in fewer cache lines. 27955 27956 If the value of this macro has a type, it should be an unsigned 27957 type. 27958 27959 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 27960 If defined, a C expression to compute the minimum required 27961 alignment for dynamic stack realignment purposes for EXP (a type 27962 or decl), MODE, assuming normal alignment ALIGN. 27963 27964 If this macro is not defined, then ALIGN will be used. 27965 27966 -- Macro: EMPTY_FIELD_BOUNDARY 27967 Alignment in bits to be given to a structure bit-field that 27968 follows an empty field such as `int : 0;'. 27969 27970 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 27971 27972 -- Macro: STRUCTURE_SIZE_BOUNDARY 27973 Number of bits which any structure or union's size must be a 27974 multiple of. Each structure or union's size is rounded up to a 27975 multiple of this. 27976 27977 If you do not define this macro, the default is the same as 27978 `BITS_PER_UNIT'. 27979 27980 -- Macro: STRICT_ALIGNMENT 27981 Define this macro to be the value 1 if instructions will fail to 27982 work if given data not on the nominal alignment. If instructions 27983 will merely go slower in that case, define this macro as 0. 27984 27985 -- Macro: PCC_BITFIELD_TYPE_MATTERS 27986 Define this if you wish to imitate the way many other C compilers 27987 handle alignment of bit-fields and the structures that contain 27988 them. 27989 27990 The behavior is that the type written for a named bit-field (`int', 27991 `short', or other integer type) imposes an alignment for the entire 27992 structure, as if the structure really did contain an ordinary 27993 field of that type. In addition, the bit-field is placed within 27994 the structure so that it would fit within such a field, not 27995 crossing a boundary for it. 27996 27997 Thus, on most machines, a named bit-field whose type is written as 27998 `int' would not cross a four-byte boundary, and would force 27999 four-byte alignment for the whole structure. (The alignment used 28000 may not be four bytes; it is controlled by the other alignment 28001 parameters.) 28002 28003 An unnamed bit-field will not affect the alignment of the 28004 containing structure. 28005 28006 If the macro is defined, its definition should be a C expression; 28007 a nonzero value for the expression enables this behavior. 28008 28009 Note that if this macro is not defined, or its value is zero, some 28010 bit-fields may cross more than one alignment boundary. The 28011 compiler can support such references if there are `insv', `extv', 28012 and `extzv' insns that can directly reference memory. 28013 28014 The other known way of making bit-fields work is to define 28015 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then 28016 every structure can be accessed with fullwords. 28017 28018 Unless the machine has bit-field instructions or you define 28019 `STRUCTURE_SIZE_BOUNDARY' that way, you must define 28020 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 28021 28022 If your aim is to make GCC use the same conventions for laying out 28023 bit-fields as are used by another compiler, here is how to 28024 investigate what the other compiler does. Compile and run this 28025 program: 28026 28027 struct foo1 28028 { 28029 char x; 28030 char :0; 28031 char y; 28032 }; 28033 28034 struct foo2 28035 { 28036 char x; 28037 int :0; 28038 char y; 28039 }; 28040 28041 main () 28042 { 28043 printf ("Size of foo1 is %d\n", 28044 sizeof (struct foo1)); 28045 printf ("Size of foo2 is %d\n", 28046 sizeof (struct foo2)); 28047 exit (0); 28048 } 28049 28050 If this prints 2 and 5, then the compiler's behavior is what you 28051 would get from `PCC_BITFIELD_TYPE_MATTERS'. 28052 28053 -- Macro: BITFIELD_NBYTES_LIMITED 28054 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 28055 to aligning a bit-field within the structure. 28056 28057 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 28058 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 28059 whether unnamed bitfields affect the alignment of the containing 28060 structure. The hook should return true if the structure should 28061 inherit the alignment requirements of an unnamed bitfield's type. 28062 28063 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 28064 This target hook should return `true' if accesses to volatile 28065 bitfields should use the narrowest mode possible. It should 28066 return `false' if these accesses should use the bitfield container 28067 type. 28068 28069 The default is `!TARGET_STRICT_ALIGN'. 28070 28071 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 28072 enum machine_mode MODE) 28073 Return true if a structure, union or array containing FIELD should 28074 be accessed using `BLKMODE'. 28075 28076 If FIELD is the only field in the structure, MODE is its mode, 28077 otherwise MODE is VOIDmode. MODE is provided in the case where 28078 structures of one field would require the structure's mode to 28079 retain the field's mode. 28080 28081 Normally, this is not needed. 28082 28083 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 28084 Define this macro as an expression for the alignment of a type 28085 (given by TYPE as a tree node) if the alignment computed in the 28086 usual way is COMPUTED and the alignment explicitly specified was 28087 SPECIFIED. 28088 28089 The default is to use SPECIFIED if it is larger; otherwise, use 28090 the smaller of COMPUTED and `BIGGEST_ALIGNMENT' 28091 28092 -- Macro: MAX_FIXED_MODE_SIZE 28093 An integer expression for the size in bits of the largest integer 28094 machine mode that should actually be used. All integer machine 28095 modes of this size or smaller can be used for structures and 28096 unions with the appropriate sizes. If this macro is undefined, 28097 `GET_MODE_BITSIZE (DImode)' is assumed. 28098 28099 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 28100 If defined, an expression of type `enum machine_mode' that 28101 specifies the mode of the save area operand of a 28102 `save_stack_LEVEL' named pattern (*note Standard Names::). 28103 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or 28104 `SAVE_NONLOCAL' and selects which of the three named patterns is 28105 having its mode specified. 28106 28107 You need not define this macro if it always returns `Pmode'. You 28108 would most commonly define this macro if the `save_stack_LEVEL' 28109 patterns need to support both a 32- and a 64-bit mode. 28110 28111 -- Macro: STACK_SIZE_MODE 28112 If defined, an expression of type `enum machine_mode' that 28113 specifies the mode of the size increment operand of an 28114 `allocate_stack' named pattern (*note Standard Names::). 28115 28116 You need not define this macro if it always returns `word_mode'. 28117 You would most commonly define this macro if the `allocate_stack' 28118 pattern needs to support both a 32- and a 64-bit mode. 28119 28120 -- Target Hook: enum machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 28121 This target hook should return the mode to be used for the return 28122 value of compare instructions expanded to libgcc calls. If not 28123 defined `word_mode' is returned which is the right choice for a 28124 majority of targets. 28125 28126 -- Target Hook: enum machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 28127 This target hook should return the mode to be used for the shift 28128 count operand of shift instructions expanded to libgcc calls. If 28129 not defined `word_mode' is returned which is the right choice for 28130 a majority of targets. 28131 28132 -- Target Hook: enum machine_mode TARGET_UNWIND_WORD_MODE (void) 28133 Return machine mode to be used for `_Unwind_Word' type. The 28134 default is to use `word_mode'. 28135 28136 -- Macro: ROUND_TOWARDS_ZERO 28137 If defined, this macro should be true if the prevailing rounding 28138 mode is towards zero. 28139 28140 Defining this macro only affects the way `libgcc.a' emulates 28141 floating-point arithmetic. 28142 28143 Not defining this macro is equivalent to returning zero. 28144 28145 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE) 28146 This macro should return true if floats with SIZE bits do not have 28147 a NaN or infinity representation, but use the largest exponent for 28148 normal numbers instead. 28149 28150 Defining this macro only affects the way `libgcc.a' emulates 28151 floating-point arithmetic. 28152 28153 The default definition of this macro returns false for all sizes. 28154 28155 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 28156 RECORD_TYPE) 28157 This target hook returns `true' if bit-fields in the given 28158 RECORD_TYPE are to be laid out following the rules of Microsoft 28159 Visual C/C++, namely: (i) a bit-field won't share the same storage 28160 unit with the previous bit-field if their underlying types have 28161 different sizes, and the bit-field will be aligned to the highest 28162 alignment of the underlying types of itself and of the previous 28163 bit-field; (ii) a zero-sized bit-field will affect the alignment of 28164 the whole enclosing structure, even if it is unnamed; except that 28165 (iii) a zero-sized bit-field will be disregarded unless it follows 28166 another bit-field of nonzero size. If this hook returns `true', 28167 other macros that control bit-field layout are ignored. 28168 28169 When a bit-field is inserted into a packed record, the whole size 28170 of the underlying type is used by one or more same-size adjacent 28171 bit-fields (that is, if its long:3, 32 bits is used in the record, 28172 and any additional adjacent long bit-fields are packed into the 28173 same chunk of 32 bits. However, if the size changes, a new field 28174 of that size is allocated). In an unpacked record, this is the 28175 same as using alignment, but not equivalent when packing. 28176 28177 If both MS bit-fields and `__attribute__((packed))' are used, the 28178 latter will take precedence. If `__attribute__((packed))' is used 28179 on a single field when MS bit-fields are in use, it will take 28180 precedence for that field, but the alignment of the rest of the 28181 structure may affect its placement. 28182 28183 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 28184 Returns true if the target supports decimal floating point. 28185 28186 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 28187 Returns true if the target supports fixed-point arithmetic. 28188 28189 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 28190 This hook is called just before expansion into rtl, allowing the 28191 target to perform additional initializations or analysis before 28192 the expansion. For example, the rs6000 port uses it to allocate a 28193 scratch stack slot for use in copying SDmode values between memory 28194 and floating point registers whenever the function being expanded 28195 has any SDmode usage. 28196 28197 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 28198 This hook allows the backend to perform additional instantiations 28199 on rtl that are not actually in any insns yet, but will be later. 28200 28201 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 28202 If your target defines any fundamental types, or any types your 28203 target uses should be mangled differently from the default, define 28204 this hook to return the appropriate encoding for these types as 28205 part of a C++ mangled name. The TYPE argument is the tree 28206 structure representing the type to be mangled. The hook may be 28207 applied to trees which are not target-specific fundamental types; 28208 it should return `NULL' for all such types, as well as arguments 28209 it does not recognize. If the return value is not `NULL', it must 28210 point to a statically-allocated string constant. 28211 28212 Target-specific fundamental types might be new fundamental types or 28213 qualified versions of ordinary fundamental types. Encode new 28214 fundamental types as `u N NAME', where NAME is the name used for 28215 the type in source code, and N is the length of NAME in decimal. 28216 Encode qualified versions of ordinary types as `U N NAME CODE', 28217 where NAME is the name used for the type qualifier in source code, 28218 N is the length of NAME as above, and CODE is the code used to 28219 represent the unqualified version of this type. (See 28220 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In 28221 both cases the spaces are for clarity; do not include any spaces 28222 in your string. 28223 28224 This hook is applied to types prior to typedef resolution. If the 28225 mangled name for a particular type depends only on that type's 28226 main variant, you can perform typedef resolution yourself using 28227 `TYPE_MAIN_VARIANT' before mangling. 28228 28229 The default version of this hook always returns `NULL', which is 28230 appropriate for a target that does not define any new fundamental 28231 types. 28232 28233 28234File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 28235 2823617.6 Layout of Source Language Data Types 28237========================================= 28238 28239These macros define the sizes and other characteristics of the standard 28240basic data types used in programs being compiled. Unlike the macros in 28241the previous section, these apply to specific features of C and related 28242languages, rather than to fundamental aspects of storage layout. 28243 28244 -- Macro: INT_TYPE_SIZE 28245 A C expression for the size in bits of the type `int' on the 28246 target machine. If you don't define this, the default is one word. 28247 28248 -- Macro: SHORT_TYPE_SIZE 28249 A C expression for the size in bits of the type `short' on the 28250 target machine. If you don't define this, the default is half a 28251 word. (If this would be less than one storage unit, it is rounded 28252 up to one unit.) 28253 28254 -- Macro: LONG_TYPE_SIZE 28255 A C expression for the size in bits of the type `long' on the 28256 target machine. If you don't define this, the default is one word. 28257 28258 -- Macro: ADA_LONG_TYPE_SIZE 28259 On some machines, the size used for the Ada equivalent of the type 28260 `long' by a native Ada compiler differs from that used by C. In 28261 that situation, define this macro to be a C expression to be used 28262 for the size of that type. If you don't define this, the default 28263 is the value of `LONG_TYPE_SIZE'. 28264 28265 -- Macro: LONG_LONG_TYPE_SIZE 28266 A C expression for the size in bits of the type `long long' on the 28267 target machine. If you don't define this, the default is two 28268 words. If you want to support GNU Ada on your machine, the value 28269 of this macro must be at least 64. 28270 28271 -- Macro: CHAR_TYPE_SIZE 28272 A C expression for the size in bits of the type `char' on the 28273 target machine. If you don't define this, the default is 28274 `BITS_PER_UNIT'. 28275 28276 -- Macro: BOOL_TYPE_SIZE 28277 A C expression for the size in bits of the C++ type `bool' and C99 28278 type `_Bool' on the target machine. If you don't define this, and 28279 you probably shouldn't, the default is `CHAR_TYPE_SIZE'. 28280 28281 -- Macro: FLOAT_TYPE_SIZE 28282 A C expression for the size in bits of the type `float' on the 28283 target machine. If you don't define this, the default is one word. 28284 28285 -- Macro: DOUBLE_TYPE_SIZE 28286 A C expression for the size in bits of the type `double' on the 28287 target machine. If you don't define this, the default is two 28288 words. 28289 28290 -- Macro: LONG_DOUBLE_TYPE_SIZE 28291 A C expression for the size in bits of the type `long double' on 28292 the target machine. If you don't define this, the default is two 28293 words. 28294 28295 -- Macro: SHORT_FRACT_TYPE_SIZE 28296 A C expression for the size in bits of the type `short _Fract' on 28297 the target machine. If you don't define this, the default is 28298 `BITS_PER_UNIT'. 28299 28300 -- Macro: FRACT_TYPE_SIZE 28301 A C expression for the size in bits of the type `_Fract' on the 28302 target machine. If you don't define this, the default is 28303 `BITS_PER_UNIT * 2'. 28304 28305 -- Macro: LONG_FRACT_TYPE_SIZE 28306 A C expression for the size in bits of the type `long _Fract' on 28307 the target machine. If you don't define this, the default is 28308 `BITS_PER_UNIT * 4'. 28309 28310 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 28311 A C expression for the size in bits of the type `long long _Fract' 28312 on the target machine. If you don't define this, the default is 28313 `BITS_PER_UNIT * 8'. 28314 28315 -- Macro: SHORT_ACCUM_TYPE_SIZE 28316 A C expression for the size in bits of the type `short _Accum' on 28317 the target machine. If you don't define this, the default is 28318 `BITS_PER_UNIT * 2'. 28319 28320 -- Macro: ACCUM_TYPE_SIZE 28321 A C expression for the size in bits of the type `_Accum' on the 28322 target machine. If you don't define this, the default is 28323 `BITS_PER_UNIT * 4'. 28324 28325 -- Macro: LONG_ACCUM_TYPE_SIZE 28326 A C expression for the size in bits of the type `long _Accum' on 28327 the target machine. If you don't define this, the default is 28328 `BITS_PER_UNIT * 8'. 28329 28330 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 28331 A C expression for the size in bits of the type `long long _Accum' 28332 on the target machine. If you don't define this, the default is 28333 `BITS_PER_UNIT * 16'. 28334 28335 -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE 28336 Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if 28337 you want routines in `libgcc2.a' for a size other than 28338 `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is 28339 `LONG_DOUBLE_TYPE_SIZE'. 28340 28341 -- Macro: LIBGCC2_HAS_DF_MODE 28342 Define this macro if neither `DOUBLE_TYPE_SIZE' nor 28343 `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode' 28344 routines in `libgcc2.a' anyway. If you don't define this and 28345 either `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 28346 then the default is 1, otherwise it is 0. 28347 28348 -- Macro: LIBGCC2_HAS_XF_MODE 28349 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 28350 `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If 28351 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80 28352 then the default is 1, otherwise it is 0. 28353 28354 -- Macro: LIBGCC2_HAS_TF_MODE 28355 Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not 28356 `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If 28357 you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128 28358 then the default is 1, otherwise it is 0. 28359 28360 -- Macro: LIBGCC2_GNU_PREFIX 28361 This macro corresponds to the `TARGET_LIBFUNC_GNU_PREFIX' target 28362 hook and should be defined if that hook is overriden to be true. 28363 It causes function names in libgcc to be changed to use a `__gnu_' 28364 prefix for their name rather than the default `__'. A port which 28365 uses this macro should also arrange to use `t-gnu-prefix' in the 28366 libgcc `config.host'. 28367 28368 -- Macro: SF_SIZE 28369 -- Macro: DF_SIZE 28370 -- Macro: XF_SIZE 28371 -- Macro: TF_SIZE 28372 Define these macros to be the size in bits of the mantissa of 28373 `SFmode', `DFmode', `XFmode' and `TFmode' values, if the defaults 28374 in `libgcc2.h' are inappropriate. By default, `FLT_MANT_DIG' is 28375 used for `SF_SIZE', `LDBL_MANT_DIG' for `XF_SIZE' and `TF_SIZE', 28376 and `DBL_MANT_DIG' or `LDBL_MANT_DIG' for `DF_SIZE' according to 28377 whether `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 28378 64. 28379 28380 -- Macro: TARGET_FLT_EVAL_METHOD 28381 A C expression for the value for `FLT_EVAL_METHOD' in `float.h', 28382 assuming, if applicable, that the floating-point control word is 28383 in its default state. If you do not define this macro the value of 28384 `FLT_EVAL_METHOD' will be zero. 28385 28386 -- Macro: WIDEST_HARDWARE_FP_SIZE 28387 A C expression for the size in bits of the widest floating-point 28388 format supported by the hardware. If you define this macro, you 28389 must specify a value less than or equal to the value of 28390 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 28391 value of `LONG_DOUBLE_TYPE_SIZE' is the default. 28392 28393 -- Macro: DEFAULT_SIGNED_CHAR 28394 An expression whose value is 1 or 0, according to whether the type 28395 `char' should be signed or unsigned by default. The user can 28396 always override this default with the options `-fsigned-char' and 28397 `-funsigned-char'. 28398 28399 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 28400 This target hook should return true if the compiler should give an 28401 `enum' type only as many bytes as it takes to represent the range 28402 of possible values of that type. It should return false if all 28403 `enum' types should be allocated like `int'. 28404 28405 The default is to return false. 28406 28407 -- Macro: SIZE_TYPE 28408 A C expression for a string describing the name of the data type 28409 to use for size values. The typedef name `size_t' is defined 28410 using the contents of the string. 28411 28412 The string can contain more than one keyword. If so, separate 28413 them with spaces, and write first any length keyword, then 28414 `unsigned' if appropriate, and finally `int'. The string must 28415 exactly match one of the data type names defined in the function 28416 `c_common_nodes_and_builtins' in the file `c-family/c-common.c'. 28417 You may not omit `int' or change the order--that would cause the 28418 compiler to crash on startup. 28419 28420 If you don't define this macro, the default is `"long unsigned 28421 int"'. 28422 28423 -- Macro: SIZETYPE 28424 GCC defines internal types (`sizetype', `ssizetype', `bitsizetype' 28425 and `sbitsizetype') for expressions dealing with size. This macro 28426 is a C expression for a string describing the name of the data 28427 type from which the precision of `sizetype' is extracted. 28428 28429 The string has the same restrictions as `SIZE_TYPE' string. 28430 28431 If you don't define this macro, the default is `SIZE_TYPE'. 28432 28433 -- Macro: PTRDIFF_TYPE 28434 A C expression for a string describing the name of the data type 28435 to use for the result of subtracting two pointers. The typedef 28436 name `ptrdiff_t' is defined using the contents of the string. See 28437 `SIZE_TYPE' above for more information. 28438 28439 If you don't define this macro, the default is `"long int"'. 28440 28441 -- Macro: WCHAR_TYPE 28442 A C expression for a string describing the name of the data type 28443 to use for wide characters. The typedef name `wchar_t' is defined 28444 using the contents of the string. See `SIZE_TYPE' above for more 28445 information. 28446 28447 If you don't define this macro, the default is `"int"'. 28448 28449 -- Macro: WCHAR_TYPE_SIZE 28450 A C expression for the size in bits of the data type for wide 28451 characters. This is used in `cpp', which cannot make use of 28452 `WCHAR_TYPE'. 28453 28454 -- Macro: WINT_TYPE 28455 A C expression for a string describing the name of the data type to 28456 use for wide characters passed to `printf' and returned from 28457 `getwc'. The typedef name `wint_t' is defined using the contents 28458 of the string. See `SIZE_TYPE' above for more information. 28459 28460 If you don't define this macro, the default is `"unsigned int"'. 28461 28462 -- Macro: INTMAX_TYPE 28463 A C expression for a string describing the name of the data type 28464 that can represent any value of any standard or extended signed 28465 integer type. The typedef name `intmax_t' is defined using the 28466 contents of the string. See `SIZE_TYPE' above for more 28467 information. 28468 28469 If you don't define this macro, the default is the first of 28470 `"int"', `"long int"', or `"long long int"' that has as much 28471 precision as `long long int'. 28472 28473 -- Macro: UINTMAX_TYPE 28474 A C expression for a string describing the name of the data type 28475 that can represent any value of any standard or extended unsigned 28476 integer type. The typedef name `uintmax_t' is defined using the 28477 contents of the string. See `SIZE_TYPE' above for more 28478 information. 28479 28480 If you don't define this macro, the default is the first of 28481 `"unsigned int"', `"long unsigned int"', or `"long long unsigned 28482 int"' that has as much precision as `long long unsigned int'. 28483 28484 -- Macro: SIG_ATOMIC_TYPE 28485 -- Macro: INT8_TYPE 28486 -- Macro: INT16_TYPE 28487 -- Macro: INT32_TYPE 28488 -- Macro: INT64_TYPE 28489 -- Macro: UINT8_TYPE 28490 -- Macro: UINT16_TYPE 28491 -- Macro: UINT32_TYPE 28492 -- Macro: UINT64_TYPE 28493 -- Macro: INT_LEAST8_TYPE 28494 -- Macro: INT_LEAST16_TYPE 28495 -- Macro: INT_LEAST32_TYPE 28496 -- Macro: INT_LEAST64_TYPE 28497 -- Macro: UINT_LEAST8_TYPE 28498 -- Macro: UINT_LEAST16_TYPE 28499 -- Macro: UINT_LEAST32_TYPE 28500 -- Macro: UINT_LEAST64_TYPE 28501 -- Macro: INT_FAST8_TYPE 28502 -- Macro: INT_FAST16_TYPE 28503 -- Macro: INT_FAST32_TYPE 28504 -- Macro: INT_FAST64_TYPE 28505 -- Macro: UINT_FAST8_TYPE 28506 -- Macro: UINT_FAST16_TYPE 28507 -- Macro: UINT_FAST32_TYPE 28508 -- Macro: UINT_FAST64_TYPE 28509 -- Macro: INTPTR_TYPE 28510 -- Macro: UINTPTR_TYPE 28511 C expressions for the standard types `sig_atomic_t', `int8_t', 28512 `int16_t', `int32_t', `int64_t', `uint8_t', `uint16_t', 28513 `uint32_t', `uint64_t', `int_least8_t', `int_least16_t', 28514 `int_least32_t', `int_least64_t', `uint_least8_t', 28515 `uint_least16_t', `uint_least32_t', `uint_least64_t', 28516 `int_fast8_t', `int_fast16_t', `int_fast32_t', `int_fast64_t', 28517 `uint_fast8_t', `uint_fast16_t', `uint_fast32_t', `uint_fast64_t', 28518 `intptr_t', and `uintptr_t'. See `SIZE_TYPE' above for more 28519 information. 28520 28521 If any of these macros evaluates to a null pointer, the 28522 corresponding type is not supported; if GCC is configured to 28523 provide `<stdint.h>' in such a case, the header provided may not 28524 conform to C99, depending on the type in question. The defaults 28525 for all of these macros are null pointers. 28526 28527 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 28528 The C++ compiler represents a pointer-to-member-function with a 28529 struct that looks like: 28530 28531 struct { 28532 union { 28533 void (*fn)(); 28534 ptrdiff_t vtable_index; 28535 }; 28536 ptrdiff_t delta; 28537 }; 28538 28539 The C++ compiler must use one bit to indicate whether the function 28540 that will be called through a pointer-to-member-function is 28541 virtual. Normally, we assume that the low-order bit of a function 28542 pointer must always be zero. Then, by ensuring that the 28543 vtable_index is odd, we can distinguish which variant of the union 28544 is in use. But, on some platforms function pointers can be odd, 28545 and so this doesn't work. In that case, we use the low-order bit 28546 of the `delta' field, and shift the remainder of the `delta' field 28547 to the left. 28548 28549 GCC will automatically make the right selection about where to 28550 store this bit using the `FUNCTION_BOUNDARY' setting for your 28551 platform. However, some platforms such as ARM/Thumb have 28552 `FUNCTION_BOUNDARY' set such that functions always start at even 28553 addresses, but the lowest bit of pointers to functions indicate 28554 whether the function at that address is in ARM or Thumb mode. If 28555 this is the case of your architecture, you should define this 28556 macro to `ptrmemfunc_vbit_in_delta'. 28557 28558 In general, you should not have to define this macro. On 28559 architectures in which function addresses are always even, 28560 according to `FUNCTION_BOUNDARY', GCC will automatically define 28561 this macro to `ptrmemfunc_vbit_in_pfn'. 28562 28563 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 28564 Normally, the C++ compiler uses function pointers in vtables. This 28565 macro allows the target to change to use "function descriptors" 28566 instead. Function descriptors are found on targets for whom a 28567 function pointer is actually a small data structure. Normally the 28568 data structure consists of the actual code address plus a data 28569 pointer to which the function's data is relative. 28570 28571 If vtables are used, the value of this macro should be the number 28572 of words that the function descriptor occupies. 28573 28574 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 28575 By default, the vtable entries are void pointers, the so the 28576 alignment is the same as pointer alignment. The value of this 28577 macro specifies the alignment of the vtable entry in bits. It 28578 should be defined only when special alignment is necessary. */ 28579 28580 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 28581 There are a few non-descriptor entries in the vtable at offsets 28582 below zero. If these entries must be padded (say, to preserve the 28583 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to 28584 the number of words in each data entry. 28585 28586 28587File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 28588 2858917.7 Register Usage 28590=================== 28591 28592This section explains how to describe what registers the target machine 28593has, and how (in general) they can be used. 28594 28595 The description of which registers a specific instruction can use is 28596done with register classes; see *note Register Classes::. For 28597information on using registers to access a stack frame, see *note Frame 28598Registers::. For passing values in registers, see *note Register 28599Arguments::. For returning values in registers, see *note Scalar 28600Return::. 28601 28602* Menu: 28603 28604* Register Basics:: Number and kinds of registers. 28605* Allocation Order:: Order in which registers are allocated. 28606* Values in Registers:: What kinds of values each reg can hold. 28607* Leaf Functions:: Renumbering registers for leaf functions. 28608* Stack Registers:: Handling a register stack such as 80387. 28609 28610 28611File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 28612 2861317.7.1 Basic Characteristics of Registers 28614----------------------------------------- 28615 28616Registers have various characteristics. 28617 28618 -- Macro: FIRST_PSEUDO_REGISTER 28619 Number of hardware registers known to the compiler. They receive 28620 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first 28621 pseudo register's number really is assigned the number 28622 `FIRST_PSEUDO_REGISTER'. 28623 28624 -- Macro: FIXED_REGISTERS 28625 An initializer that says which registers are used for fixed 28626 purposes all throughout the compiled code and are therefore not 28627 available for general allocation. These would include the stack 28628 pointer, the frame pointer (except on machines where that can be 28629 used as a general register when no frame pointer is needed), the 28630 program counter on machines where that is considered one of the 28631 addressable registers, and any other numbered register with a 28632 standard use. 28633 28634 This information is expressed as a sequence of numbers, separated 28635 by commas and surrounded by braces. The Nth number is 1 if 28636 register N is fixed, 0 otherwise. 28637 28638 The table initialized from this macro, and the table initialized by 28639 the following one, may be overridden at run time either 28640 automatically, by the actions of the macro 28641 `CONDITIONAL_REGISTER_USAGE', or by the user with the command 28642 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. 28643 28644 -- Macro: CALL_USED_REGISTERS 28645 Like `FIXED_REGISTERS' but has 1 for each register that is 28646 clobbered (in general) by function calls as well as for fixed 28647 registers. This macro therefore identifies the registers that are 28648 not available for general allocation of values that must live 28649 across function calls. 28650 28651 If a register has 0 in `CALL_USED_REGISTERS', the compiler 28652 automatically saves it on function entry and restores it on 28653 function exit, if the register is used within the function. 28654 28655 -- Macro: CALL_REALLY_USED_REGISTERS 28656 Like `CALL_USED_REGISTERS' except this macro doesn't require that 28657 the entire set of `FIXED_REGISTERS' be included. 28658 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS'). 28659 This macro is optional. If not specified, it defaults to the value 28660 of `CALL_USED_REGISTERS'. 28661 28662 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 28663 A C expression that is nonzero if it is not permissible to store a 28664 value of mode MODE in hard register number REGNO across a call 28665 without some part of it being clobbered. For most machines this 28666 macro need not be defined. It is only required for machines that 28667 do not preserve the entire contents of a register across a call. 28668 28669 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 28670 This hook may conditionally modify five variables `fixed_regs', 28671 `call_used_regs', `global_regs', `reg_names', and 28672 `reg_class_contents', to take into account any dependence of these 28673 register sets on target flags. The first three of these are of 28674 type `char []' (interpreted as Boolean vectors). `global_regs' is 28675 a `const char *[]', and `reg_class_contents' is a `HARD_REG_SET'. 28676 Before the macro is called, `fixed_regs', `call_used_regs', 28677 `reg_class_contents', and `reg_names' have been initialized from 28678 `FIXED_REGISTERS', `CALL_USED_REGISTERS', `REG_CLASS_CONTENTS', 28679 and `REGISTER_NAMES', respectively. `global_regs' has been 28680 cleared, and any `-ffixed-REG', `-fcall-used-REG' and 28681 `-fcall-saved-REG' command options have been applied. 28682 28683 If the usage of an entire class of registers depends on the target 28684 flags, you may indicate this to GCC by using this macro to modify 28685 `fixed_regs' and `call_used_regs' to 1 for each of the registers 28686 in the classes which should not be used by GCC. Also define the 28687 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to 28688 return `NO_REGS' if it is called with a letter for a class that 28689 shouldn't be used. 28690 28691 (However, if this class is not included in `GENERAL_REGS' and all 28692 of the insn patterns whose constraints permit this class are 28693 controlled by target switches, then GCC will automatically avoid 28694 using these registers when the target switches are opposed to 28695 them.) 28696 28697 -- Macro: INCOMING_REGNO (OUT) 28698 Define this macro if the target machine has register windows. 28699 This C expression returns the register number as seen by the 28700 called function corresponding to the register number OUT as seen 28701 by the calling function. Return OUT if register number OUT is not 28702 an outbound register. 28703 28704 -- Macro: OUTGOING_REGNO (IN) 28705 Define this macro if the target machine has register windows. 28706 This C expression returns the register number as seen by the 28707 calling function corresponding to the register number IN as seen 28708 by the called function. Return IN if register number IN is not an 28709 inbound register. 28710 28711 -- Macro: LOCAL_REGNO (REGNO) 28712 Define this macro if the target machine has register windows. 28713 This C expression returns true if the register is call-saved but 28714 is in the register window. Unlike most call-saved registers, such 28715 registers need not be explicitly restored on function exit or 28716 during non-local gotos. 28717 28718 -- Macro: PC_REGNUM 28719 If the program counter has a register number, define this as that 28720 register number. Otherwise, do not define it. 28721 28722 28723File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 28724 2872517.7.2 Order of Allocation of Registers 28726--------------------------------------- 28727 28728Registers are allocated in order. 28729 28730 -- Macro: REG_ALLOC_ORDER 28731 If defined, an initializer for a vector of integers, containing the 28732 numbers of hard registers in the order in which GCC should prefer 28733 to use them (from most preferred to least). 28734 28735 If this macro is not defined, registers are used lowest numbered 28736 first (all else being equal). 28737 28738 One use of this macro is on machines where the highest numbered 28739 registers must always be saved and the save-multiple-registers 28740 instruction supports only sequences of consecutive registers. On 28741 such machines, define `REG_ALLOC_ORDER' to be an initializer that 28742 lists the highest numbered allocable register first. 28743 28744 -- Macro: ADJUST_REG_ALLOC_ORDER 28745 A C statement (sans semicolon) to choose the order in which to 28746 allocate hard registers for pseudo-registers local to a basic 28747 block. 28748 28749 Store the desired register order in the array `reg_alloc_order'. 28750 Element 0 should be the register to allocate first; element 1, the 28751 next register; and so on. 28752 28753 The macro body should not assume anything about the contents of 28754 `reg_alloc_order' before execution of the macro. 28755 28756 On most machines, it is not necessary to define this macro. 28757 28758 -- Macro: HONOR_REG_ALLOC_ORDER 28759 Normally, IRA tries to estimate the costs for saving a register in 28760 the prologue and restoring it in the epilogue. This discourages 28761 it from using call-saved registers. If a machine wants to ensure 28762 that IRA allocates registers in the order given by REG_ALLOC_ORDER 28763 even if some call-saved registers appear earlier than call-used 28764 ones, this macro should be defined. 28765 28766 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 28767 In some case register allocation order is not enough for the 28768 Integrated Register Allocator (IRA) to generate a good code. If 28769 this macro is defined, it should return a floating point value 28770 based on REGNO. The cost of using REGNO for a pseudo will be 28771 increased by approximately the pseudo's usage frequency times the 28772 value returned by this macro. Not defining this macro is 28773 equivalent to having it always return `0.0'. 28774 28775 On most machines, it is not necessary to define this macro. 28776 28777 28778File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 28779 2878017.7.3 How Values Fit in Registers 28781---------------------------------- 28782 28783This section discusses the macros that describe which kinds of values 28784(specifically, which machine modes) each register can hold, and how many 28785consecutive registers are needed for a given mode. 28786 28787 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 28788 A C expression for the number of consecutive hard registers, 28789 starting at register number REGNO, required to hold a value of mode 28790 MODE. This macro must never return zero, even if a register 28791 cannot hold the requested mode - indicate that with 28792 HARD_REGNO_MODE_OK and/or CANNOT_CHANGE_MODE_CLASS instead. 28793 28794 On a machine where all registers are exactly one word, a suitable 28795 definition of this macro is 28796 28797 #define HARD_REGNO_NREGS(REGNO, MODE) \ 28798 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 28799 / UNITS_PER_WORD) 28800 28801 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 28802 A C expression that is nonzero if a value of mode MODE, stored in 28803 memory, ends with padding that causes it to take up more space than 28804 in registers starting at register number REGNO (as determined by 28805 multiplying GCC's notion of the size of the register when 28806 containing this mode by the number of registers returned by 28807 `HARD_REGNO_NREGS'). By default this is zero. 28808 28809 For example, if a floating-point value is stored in three 32-bit 28810 registers but takes up 128 bits in memory, then this would be 28811 nonzero. 28812 28813 This macros only needs to be defined if there are cases where 28814 `subreg_get_info' would otherwise wrongly determine that a 28815 `subreg' can be represented by an offset to the register number, 28816 when in fact such a `subreg' would contain some of the padding not 28817 stored in registers and so not be representable. 28818 28819 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 28820 For values of REGNO and MODE for which 28821 `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 28822 returning the greater number of registers required to hold the 28823 value including any padding. In the example above, the value 28824 would be four. 28825 28826 -- Macro: REGMODE_NATURAL_SIZE (MODE) 28827 Define this macro if the natural size of registers that hold values 28828 of mode MODE is not the word size. It is a C expression that 28829 should give the natural size in bytes for the specified mode. It 28830 is used by the register allocator to try to optimize its results. 28831 This happens for example on SPARC 64-bit where the natural size of 28832 floating-point registers is still 32-bit. 28833 28834 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 28835 A C expression that is nonzero if it is permissible to store a 28836 value of mode MODE in hard register number REGNO (or in several 28837 registers starting with that one). For a machine where all 28838 registers are equivalent, a suitable definition is 28839 28840 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 28841 28842 You need not include code to check for the numbers of fixed 28843 registers, because the allocation mechanism considers them to be 28844 always occupied. 28845 28846 On some machines, double-precision values must be kept in even/odd 28847 register pairs. You can implement that by defining this macro to 28848 reject odd register numbers for such modes. 28849 28850 The minimum requirement for a mode to be OK in a register is that 28851 the `movMODE' instruction pattern support moves between the 28852 register and other hard register in the same class and that moving 28853 a value into the register and back out not alter it. 28854 28855 Since the same instruction used to move `word_mode' will work for 28856 all narrower integer modes, it is not necessary on any machine for 28857 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided 28858 you define patterns `movhi', etc., to take advantage of this. This 28859 is useful because of the interaction between `HARD_REGNO_MODE_OK' 28860 and `MODES_TIEABLE_P'; it is very desirable for all integer modes 28861 to be tieable. 28862 28863 Many machines have special registers for floating point arithmetic. 28864 Often people assume that floating point machine modes are allowed 28865 only in floating point registers. This is not true. Any 28866 registers that can hold integers can safely _hold_ a floating 28867 point machine mode, whether or not floating arithmetic can be done 28868 on it in those registers. Integer move instructions can be used 28869 to move the values. 28870 28871 On some machines, though, the converse is true: fixed-point machine 28872 modes may not go in floating registers. This is true if the 28873 floating registers normalize any value stored in them, because 28874 storing a non-floating value there would garble it. In this case, 28875 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 28876 floating registers. But if the floating registers do not 28877 automatically normalize, if you can store any bit pattern in one 28878 and retrieve it unchanged without a trap, then any machine mode 28879 may go in a floating register, so you can define this macro to say 28880 so. 28881 28882 The primary significance of special floating registers is rather 28883 that they are the registers acceptable in floating point arithmetic 28884 instructions. However, this is of no concern to 28885 `HARD_REGNO_MODE_OK'. You handle it by writing the proper 28886 constraints for those instructions. 28887 28888 On some machines, the floating registers are especially slow to 28889 access, so that it is better to store a value in a stack frame 28890 than in such a register if floating point arithmetic is not being 28891 done. As long as the floating registers are not in class 28892 `GENERAL_REGS', they will not be used unless some pattern's 28893 constraint asks for one. 28894 28895 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 28896 A C expression that is nonzero if it is OK to rename a hard 28897 register FROM to another hard register TO. 28898 28899 One common use of this macro is to prevent renaming of a register 28900 to another register that is not saved by a prologue in an interrupt 28901 handler. 28902 28903 The default is always nonzero. 28904 28905 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 28906 A C expression that is nonzero if a value of mode MODE1 is 28907 accessible in mode MODE2 without copying. 28908 28909 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, 28910 MODE2)' are always the same for any R, then `MODES_TIEABLE_P 28911 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 28912 should define this macro to return zero unless some other 28913 mechanism ensures the accessibility of the value in a narrower 28914 mode. 28915 28916 You should define this macro to return nonzero in as many cases as 28917 possible since doing so will allow GCC to perform better register 28918 allocation. 28919 28920 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 28921 This target hook should return `true' if it is OK to use a hard 28922 register REGNO as scratch reg in peephole2. 28923 28924 One common use of this macro is to prevent using of a register that 28925 is not saved by a prologue in an interrupt handler. 28926 28927 The default version of this hook always returns `true'. 28928 28929 -- Macro: AVOID_CCMODE_COPIES 28930 Define this macro if the compiler should avoid copies to/from 28931 `CCmode' registers. You should only define this macro if support 28932 for copying to/from `CCmode' is incomplete. 28933 28934 28935File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 28936 2893717.7.4 Handling Leaf Functions 28938------------------------------ 28939 28940On some machines, a leaf function (i.e., one which makes no calls) can 28941run more efficiently if it does not make its own register window. 28942Often this means it is required to receive its arguments in the 28943registers where they are passed by the caller, instead of the registers 28944where they would normally arrive. 28945 28946 The special treatment for leaf functions generally applies only when 28947other conditions are met; for example, often they may use only those 28948registers for its own variables and temporaries. We use the term "leaf 28949function" to mean a function that is suitable for this special 28950handling, so that functions with no calls are not necessarily "leaf 28951functions". 28952 28953 GCC assigns register numbers before it knows whether the function is 28954suitable for leaf function treatment. So it needs to renumber the 28955registers in order to output a leaf function. The following macros 28956accomplish this. 28957 28958 -- Macro: LEAF_REGISTERS 28959 Name of a char vector, indexed by hard register number, which 28960 contains 1 for a register that is allowable in a candidate for leaf 28961 function treatment. 28962 28963 If leaf function treatment involves renumbering the registers, 28964 then the registers marked here should be the ones before 28965 renumbering--those that GCC would ordinarily allocate. The 28966 registers which will actually be used in the assembler code, after 28967 renumbering, should not be marked with 1 in this vector. 28968 28969 Define this macro only if the target machine offers a way to 28970 optimize the treatment of leaf functions. 28971 28972 -- Macro: LEAF_REG_REMAP (REGNO) 28973 A C expression whose value is the register number to which REGNO 28974 should be renumbered, when a function is treated as a leaf 28975 function. 28976 28977 If REGNO is a register number which should not appear in a leaf 28978 function before renumbering, then the expression should yield -1, 28979 which will cause the compiler to abort. 28980 28981 Define this macro only if the target machine offers a way to 28982 optimize the treatment of leaf functions, and registers need to be 28983 renumbered to do this. 28984 28985 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must 28986usually treat leaf functions specially. They can test the C variable 28987`current_function_is_leaf' which is nonzero for leaf functions. 28988`current_function_is_leaf' is set prior to local register allocation 28989and is valid for the remaining compiler passes. They can also test the 28990C variable `current_function_uses_only_leaf_regs' which is nonzero for 28991leaf functions which only use leaf registers. 28992`current_function_uses_only_leaf_regs' is valid after all passes that 28993modify the instructions have been run and is only useful if 28994`LEAF_REGISTERS' is defined. 28995 28996 28997File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 28998 2899917.7.5 Registers That Form a Stack 29000---------------------------------- 29001 29002There are special features to handle computers where some of the 29003"registers" form a stack. Stack registers are normally written by 29004pushing onto the stack, and are numbered relative to the top of the 29005stack. 29006 29007 Currently, GCC can only handle one group of stack-like registers, and 29008they must be consecutively numbered. Furthermore, the existing support 29009for stack-like registers is specific to the 80387 floating point 29010coprocessor. If you have a new architecture that uses stack-like 29011registers, you will need to do substantial work on `reg-stack.c' and 29012write your machine description to cooperate with it, as well as 29013defining these macros. 29014 29015 -- Macro: STACK_REGS 29016 Define this if the machine has any stack-like registers. 29017 29018 -- Macro: STACK_REG_COVER_CLASS 29019 This is a cover class containing the stack registers. Define this 29020 if the machine has any stack-like registers. 29021 29022 -- Macro: FIRST_STACK_REG 29023 The number of the first stack-like register. This one is the top 29024 of the stack. 29025 29026 -- Macro: LAST_STACK_REG 29027 The number of the last stack-like register. This one is the 29028 bottom of the stack. 29029 29030 29031File: gccint.info, Node: Register Classes, Next: Old Constraints, Prev: Registers, Up: Target Macros 29032 2903317.8 Register Classes 29034===================== 29035 29036On many machines, the numbered registers are not all equivalent. For 29037example, certain registers may not be allowed for indexed addressing; 29038certain registers may not be allowed in some instructions. These 29039machine restrictions are described to the compiler using "register 29040classes". 29041 29042 You define a number of register classes, giving each one a name and 29043saying which of the registers belong to it. Then you can specify 29044register classes that are allowed as operands to particular instruction 29045patterns. 29046 29047 In general, each register will belong to several classes. In fact, one 29048class must be named `ALL_REGS' and contain all the registers. Another 29049class must be named `NO_REGS' and contain no registers. Often the 29050union of two classes will be another class; however, this is not 29051required. 29052 29053 One of the classes must be named `GENERAL_REGS'. There is nothing 29054terribly special about the name, but the operand constraint letters `r' 29055and `g' specify this class. If `GENERAL_REGS' is the same as 29056`ALL_REGS', just define it as a macro which expands to `ALL_REGS'. 29057 29058 Order the classes so that if class X is contained in class Y then X 29059has a lower class number than Y. 29060 29061 The way classes other than `GENERAL_REGS' are specified in operand 29062constraints is through machine-dependent operand constraint letters. 29063You can define such letters to correspond to various classes, then use 29064them in operand constraints. 29065 29066 You must define the narrowest register classes for allocatable 29067registers, so that each class either has no subclasses, or that for 29068some mode, the move cost between registers within the class is cheaper 29069than moving a register in the class to or from memory (*note Costs::). 29070 29071 You should define a class for the union of two classes whenever some 29072instruction allows both classes. For example, if an instruction allows 29073either a floating point (coprocessor) register or a general register 29074for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' 29075which includes both of them. Otherwise you will get suboptimal code, 29076or even internal compiler errors when reload cannot find a register in 29077the class computed via `reg_class_subunion'. 29078 29079 You must also specify certain redundant information about the register 29080classes: for each class, which classes contain it and which ones are 29081contained in it; for each pair of classes, the largest class contained 29082in their union. 29083 29084 When a value occupying several consecutive registers is expected in a 29085certain class, all the registers used must belong to that class. 29086Therefore, register classes cannot be used to enforce a requirement for 29087a register pair to start with an even-numbered register. The way to 29088specify this requirement is with `HARD_REGNO_MODE_OK'. 29089 29090 Register classes used for input-operands of bitwise-and or shift 29091instructions have a special requirement: each such class must have, for 29092each fixed-point machine mode, a subclass whose registers can transfer 29093that mode to or from memory. For example, on some machines, the 29094operations for single-byte values (`QImode') are limited to certain 29095registers. When this is so, each register class that is used in a 29096bitwise-and or shift instruction must have a subclass consisting of 29097registers from which single-byte values can be loaded or stored. This 29098is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to 29099return. 29100 29101 -- Data type: enum reg_class 29102 An enumerated type that must be defined with all the register 29103 class names as enumerated values. `NO_REGS' must be first. 29104 `ALL_REGS' must be the last register class, followed by one more 29105 enumerated value, `LIM_REG_CLASSES', which is not a register class 29106 but rather tells how many classes there are. 29107 29108 Each register class has a number, which is the value of casting 29109 the class name to type `int'. The number serves as an index in 29110 many of the tables described below. 29111 29112 -- Macro: N_REG_CLASSES 29113 The number of distinct register classes, defined as follows: 29114 29115 #define N_REG_CLASSES (int) LIM_REG_CLASSES 29116 29117 -- Macro: REG_CLASS_NAMES 29118 An initializer containing the names of the register classes as C 29119 string constants. These names are used in writing some of the 29120 debugging dumps. 29121 29122 -- Macro: REG_CLASS_CONTENTS 29123 An initializer containing the contents of the register classes, as 29124 integers which are bit masks. The Nth integer specifies the 29125 contents of class N. The way the integer MASK is interpreted is 29126 that register R is in the class if `MASK & (1 << R)' is 1. 29127 29128 When the machine has more than 32 registers, an integer does not 29129 suffice. Then the integers are replaced by sub-initializers, 29130 braced groupings containing several integers. Each 29131 sub-initializer must be suitable as an initializer for the type 29132 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this 29133 situation, the first integer in each sub-initializer corresponds to 29134 registers 0 through 31, the second integer to registers 32 through 29135 63, and so on. 29136 29137 -- Macro: REGNO_REG_CLASS (REGNO) 29138 A C expression whose value is a register class containing hard 29139 register REGNO. In general there is more than one such class; 29140 choose a class which is "minimal", meaning that no smaller class 29141 also contains the register. 29142 29143 -- Macro: BASE_REG_CLASS 29144 A macro whose definition is the name of the class to which a valid 29145 base register must belong. A base register is one used in an 29146 address which is the register value plus a displacement. 29147 29148 -- Macro: MODE_BASE_REG_CLASS (MODE) 29149 This is a variation of the `BASE_REG_CLASS' macro which allows the 29150 selection of a base register in a mode dependent manner. If MODE 29151 is VOIDmode then it should return the same value as 29152 `BASE_REG_CLASS'. 29153 29154 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 29155 A C expression whose value is the register class to which a valid 29156 base register must belong in order to be used in a base plus index 29157 register address. You should define this macro if base plus index 29158 addresses have different requirements than other base register 29159 uses. 29160 29161 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 29162 INDEX_CODE) 29163 A C expression whose value is the register class to which a valid 29164 base register for a memory reference in mode MODE to address space 29165 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 29166 context in which the base register occurs. OUTER_CODE is the code 29167 of the immediately enclosing expression (`MEM' for the top level 29168 of an address, `ADDRESS' for something that occurs in an 29169 `address_operand'). INDEX_CODE is the code of the corresponding 29170 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 29171 29172 -- Macro: INDEX_REG_CLASS 29173 A macro whose definition is the name of the class to which a valid 29174 index register must belong. An index register is one used in an 29175 address where its value is either multiplied by a scale factor or 29176 added to another register (as well as added to a displacement). 29177 29178 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 29179 A C expression which is nonzero if register number NUM is suitable 29180 for use as a base register in operand addresses. 29181 29182 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 29183 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that 29184 that expression may examine the mode of the memory reference in 29185 MODE. You should define this macro if the mode of the memory 29186 reference affects whether a register may be used as a base 29187 register. If you define this macro, the compiler will use it 29188 instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for 29189 addresses that appear outside a `MEM', i.e., as an 29190 `address_operand'. 29191 29192 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 29193 A C expression which is nonzero if register number NUM is suitable 29194 for use as a base register in base plus index operand addresses, 29195 accessing memory in mode MODE. It may be either a suitable hard 29196 register or a pseudo register that has been allocated such a hard 29197 register. You should define this macro if base plus index 29198 addresses have different requirements than other base register 29199 uses. 29200 29201 Use of this macro is deprecated; please use the more general 29202 `REGNO_MODE_CODE_OK_FOR_BASE_P'. 29203 29204 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 29205 OUTER_CODE, INDEX_CODE) 29206 A C expression which is nonzero if register number NUM is suitable 29207 for use as a base register in operand addresses, accessing memory 29208 in mode MODE in address space ADDRESS_SPACE. This is similar to 29209 `REGNO_MODE_OK_FOR_BASE_P', except that that expression may 29210 examine the context in which the register appears in the memory 29211 reference. OUTER_CODE is the code of the immediately enclosing 29212 expression (`MEM' if at the top level of the address, `ADDRESS' 29213 for something that occurs in an `address_operand'). INDEX_CODE is 29214 the code of the corresponding index expression if OUTER_CODE is 29215 `PLUS'; `SCRATCH' otherwise. The mode may be `VOIDmode' for 29216 addresses that appear outside a `MEM', i.e., as an 29217 `address_operand'. 29218 29219 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 29220 A C expression which is nonzero if register number NUM is suitable 29221 for use as an index register in operand addresses. It may be 29222 either a suitable hard register or a pseudo register that has been 29223 allocated such a hard register. 29224 29225 The difference between an index register and a base register is 29226 that the index register may be scaled. If an address involves the 29227 sum of two registers, neither one of them scaled, then either one 29228 may be labeled the "base" and the other the "index"; but whichever 29229 labeling is used must fit the machine's constraints of which 29230 registers may serve in each capacity. The compiler will try both 29231 labelings, looking for one that is valid, and will reload one or 29232 both registers only if neither labeling works. 29233 29234 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 29235 RCLASS) 29236 A target hook that places additional preference on the register 29237 class to use when it is necessary to rename a register in class 29238 RCLASS to another class, or perhaps NO_REGS, if no preferred 29239 register class is found or hook `preferred_rename_class' is not 29240 implemented. Sometimes returning a more restrictive class makes 29241 better code. For example, on ARM, thumb-2 instructions using 29242 `LO_REGS' may be smaller than instructions using `GENERIC_REGS'. 29243 By returning `LO_REGS' from `preferred_rename_class', code size 29244 can be reduced. 29245 29246 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 29247 reg_class_t RCLASS) 29248 A target hook that places additional restrictions on the register 29249 class to use when it is necessary to copy value X into a register 29250 in class RCLASS. The value is a register class; perhaps RCLASS, 29251 or perhaps another, smaller class. 29252 29253 The default version of this hook always returns value of `rclass' 29254 argument. 29255 29256 Sometimes returning a more restrictive class makes better code. 29257 For example, on the 68000, when X is an integer constant that is 29258 in range for a `moveq' instruction, the value of this macro is 29259 always `DATA_REGS' as long as RCLASS includes the data registers. 29260 Requiring a data register guarantees that a `moveq' will be used. 29261 29262 One case where `TARGET_PREFERRED_RELOAD_CLASS' must not return 29263 RCLASS is if X is a legitimate constant which cannot be loaded 29264 into some register class. By returning `NO_REGS' you can force X 29265 into a memory location. For example, rs6000 can load immediate 29266 values into general-purpose registers, but does not have an 29267 instruction for loading an immediate value into a floating-point 29268 register, so `TARGET_PREFERRED_RELOAD_CLASS' returns `NO_REGS' when 29269 X is a floating-point constant. If the constant can't be loaded 29270 into any kind of register, code generation will be better if 29271 `TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 29272 instead of using `TARGET_PREFERRED_RELOAD_CLASS'. 29273 29274 If an insn has pseudos in it after register allocation, reload 29275 will go through the alternatives and call repeatedly 29276 `TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 29277 `NO_REGS', in this case, makes reload add a `!' in front of the 29278 constraint: the x86 back-end uses this feature to discourage usage 29279 of 387 registers when math is done in the SSE registers (and vice 29280 versa). 29281 29282 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 29283 A C expression that places additional restrictions on the register 29284 class to use when it is necessary to copy value X into a register 29285 in class CLASS. The value is a register class; perhaps CLASS, or 29286 perhaps another, smaller class. On many machines, the following 29287 definition is safe: 29288 29289 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 29290 29291 Sometimes returning a more restrictive class makes better code. 29292 For example, on the 68000, when X is an integer constant that is 29293 in range for a `moveq' instruction, the value of this macro is 29294 always `DATA_REGS' as long as CLASS includes the data registers. 29295 Requiring a data register guarantees that a `moveq' will be used. 29296 29297 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is 29298 if X is a legitimate constant which cannot be loaded into some 29299 register class. By returning `NO_REGS' you can force X into a 29300 memory location. For example, rs6000 can load immediate values 29301 into general-purpose registers, but does not have an instruction 29302 for loading an immediate value into a floating-point register, so 29303 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a 29304 floating-point constant. If the constant can't be loaded into any 29305 kind of register, code generation will be better if 29306 `TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 29307 instead of using `TARGET_PREFERRED_RELOAD_CLASS'. 29308 29309 If an insn has pseudos in it after register allocation, reload 29310 will go through the alternatives and call repeatedly 29311 `PREFERRED_RELOAD_CLASS' to find the best one. Returning 29312 `NO_REGS', in this case, makes reload add a `!' in front of the 29313 constraint: the x86 back-end uses this feature to discourage usage 29314 of 387 registers when math is done in the SSE registers (and vice 29315 versa). 29316 29317 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 29318 X, reg_class_t RCLASS) 29319 Like `TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 29320 instead of input reloads. 29321 29322 The default version of this hook always returns value of `rclass' 29323 argument. 29324 29325 You can also use `TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 29326 discourage reload from using some alternatives, like 29327 `TARGET_PREFERRED_RELOAD_CLASS'. 29328 29329 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 29330 A C expression that places additional restrictions on the register 29331 class to use when it is necessary to be able to hold a value of 29332 mode MODE in a reload register for which class CLASS would 29333 ordinarily be used. 29334 29335 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when 29336 there are certain modes that simply can't go in certain reload 29337 classes. 29338 29339 The value is a register class; perhaps CLASS, or perhaps another, 29340 smaller class. 29341 29342 Don't define this macro unless the target machine has limitations 29343 which require the macro to do something nontrivial. 29344 29345 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 29346 reg_class_t RELOAD_CLASS, enum machine_mode RELOAD_MODE, 29347 secondary_reload_info *SRI) 29348 Many machines have some registers that cannot be copied directly 29349 to or from memory or even from other types of registers. An 29350 example is the `MQ' register, which on most machines, can only be 29351 copied to or from general registers, but not memory. Below, we 29352 shall be using the term 'intermediate register' when a move 29353 operation cannot be performed directly, but has to be done by 29354 copying the source into the intermediate register first, and then 29355 copying the intermediate register to the destination. An 29356 intermediate register always has the same mode as source and 29357 destination. Since it holds the actual value being copied, reload 29358 might apply optimizations to re-use an intermediate register and 29359 eliding the copy from the source when it can determine that the 29360 intermediate register still holds the required value. 29361 29362 Another kind of secondary reload is required on some machines which 29363 allow copying all registers to and from memory, but require a 29364 scratch register for stores to some memory locations (e.g., those 29365 with symbolic address on the RT, and those with certain symbolic 29366 address on the SPARC when compiling PIC). Scratch registers need 29367 not have the same mode as the value being copied, and usually hold 29368 a different value than that being copied. Special patterns in the 29369 md file are needed to describe how the copy is performed with the 29370 help of the scratch register; these patterns also describe the 29371 number, register class(es) and mode(s) of the scratch register(s). 29372 29373 In some cases, both an intermediate and a scratch register are 29374 required. 29375 29376 For input reloads, this target hook is called with nonzero IN_P, 29377 and X is an rtx that needs to be copied to a register of class 29378 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 29379 is called with zero IN_P, and a register of class RELOAD_CLASS 29380 needs to be copied to rtx X in RELOAD_MODE. 29381 29382 If copying a register of RELOAD_CLASS from/to X requires an 29383 intermediate register, the hook `secondary_reload' should return 29384 the register class required for this intermediate register. If no 29385 intermediate register is required, it should return NO_REGS. If 29386 more than one intermediate register is required, describe the one 29387 that is closest in the copy chain to the reload register. 29388 29389 If scratch registers are needed, you also have to describe how to 29390 perform the copy from/to the reload register to/from this closest 29391 intermediate register. Or if no intermediate register is 29392 required, but still a scratch register is needed, describe the 29393 copy from/to the reload register to/from the reload operand X. 29394 29395 You do this by setting `sri->icode' to the instruction code of a 29396 pattern in the md file which performs the move. Operands 0 and 1 29397 are the output and input of this copy, respectively. Operands 29398 from operand 2 onward are for scratch operands. These scratch 29399 operands must have a mode, and a single-register-class output 29400 constraint. 29401 29402 When an intermediate register is used, the `secondary_reload' hook 29403 will be called again to determine how to copy the intermediate 29404 register to/from the reload operand X, so your hook must also have 29405 code to handle the register class of the intermediate operand. 29406 29407 X might be a pseudo-register or a `subreg' of a pseudo-register, 29408 which could either be in a hard register or in memory. Use 29409 `true_regnum' to find out; it will return -1 if the pseudo is in 29410 memory and the hard register number if it is in a register. 29411 29412 Scratch operands in memory (constraint `"=m"' / `"=&m"') are 29413 currently not supported. For the time being, you will have to 29414 continue to use `SECONDARY_MEMORY_NEEDED' for that purpose. 29415 29416 `copy_cost' also uses this target hook to find out how values are 29417 copied. If you want it to include some extra cost for the need to 29418 allocate (a) scratch register(s), set `sri->extra_cost' to the 29419 additional cost. Or if two dependent moves are supposed to have a 29420 lower cost than the sum of the individual moves due to expected 29421 fortuitous scheduling and/or special forwarding logic, you can set 29422 `sri->extra_cost' to a negative amount. 29423 29424 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 29425 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 29426 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 29427 These macros are obsolete, new ports should use the target hook 29428 `TARGET_SECONDARY_RELOAD' instead. 29429 29430 These are obsolete macros, replaced by the 29431 `TARGET_SECONDARY_RELOAD' target hook. Older ports still define 29432 these macros to indicate to the reload phase that it may need to 29433 allocate at least one register for a reload in addition to the 29434 register to contain the data. Specifically, if copying X to a 29435 register CLASS in MODE requires an intermediate register, you were 29436 supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the 29437 largest register class all of whose registers can be used as 29438 intermediate registers or scratch registers. 29439 29440 If copying a register CLASS in MODE to X requires an intermediate 29441 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 29442 to be defined be defined to return the largest register class 29443 required. If the requirements for input and output reloads were 29444 the same, the macro `SECONDARY_RELOAD_CLASS' should have been used 29445 instead of defining both macros identically. 29446 29447 The values returned by these macros are often `GENERAL_REGS'. 29448 Return `NO_REGS' if no spare register is needed; i.e., if X can be 29449 directly copied to or from a register of CLASS in MODE without 29450 requiring a scratch register. Do not define this macro if it 29451 would always return `NO_REGS'. 29452 29453 If a scratch register is required (either with or without an 29454 intermediate register), you were supposed to define patterns for 29455 `reload_inM' or `reload_outM', as required (*note Standard 29456 Names::. These patterns, which were normally implemented with a 29457 `define_expand', should be similar to the `movM' patterns, except 29458 that operand 2 is the scratch register. 29459 29460 These patterns need constraints for the reload register and scratch 29461 register that contain a single register class. If the original 29462 reload register (whose class is CLASS) can meet the constraint 29463 given in the pattern, the value returned by these macros is used 29464 for the class of the scratch register. Otherwise, two additional 29465 reload registers are required. Their classes are obtained from 29466 the constraints in the insn pattern. 29467 29468 X might be a pseudo-register or a `subreg' of a pseudo-register, 29469 which could either be in a hard register or in memory. Use 29470 `true_regnum' to find out; it will return -1 if the pseudo is in 29471 memory and the hard register number if it is in a register. 29472 29473 These macros should not be used in the case where a particular 29474 class of registers can only be copied to memory and not to another 29475 class of registers. In that case, secondary reload registers are 29476 not needed and would not be helpful. Instead, a stack location 29477 must be used to perform the copy and the `movM' pattern should use 29478 memory as an intermediate storage. This case often occurs between 29479 floating-point and general registers. 29480 29481 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 29482 Certain machines have the property that some registers cannot be 29483 copied to some other registers without using memory. Define this 29484 macro on those machines to be a C expression that is nonzero if 29485 objects of mode M in registers of CLASS1 can only be copied to 29486 registers of class CLASS2 by storing a register of CLASS1 into 29487 memory and loading that memory location into a register of CLASS2. 29488 29489 Do not define this macro if its value would always be zero. 29490 29491 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 29492 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler 29493 allocates a stack slot for a memory location needed for register 29494 copies. If this macro is defined, the compiler instead uses the 29495 memory location defined by this macro. 29496 29497 Do not define this macro if you do not define 29498 `SECONDARY_MEMORY_NEEDED'. 29499 29500 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 29501 When the compiler needs a secondary memory location to copy 29502 between two registers of mode MODE, it normally allocates 29503 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and 29504 performs the store and load operations in a mode that many bits 29505 wide and whose class is the same as that of MODE. 29506 29507 This is right thing to do on most machines because it ensures that 29508 all bits of the register are copied and prevents accesses to the 29509 registers in a narrower mode, which some machines prohibit for 29510 floating-point registers. 29511 29512 However, this default behavior is not correct on some machines, 29513 such as the DEC Alpha, that store short integers in floating-point 29514 registers differently than in integer registers. On those 29515 machines, the default widening will not work correctly and you 29516 must define this macro to suppress that widening in some cases. 29517 See the file `alpha.h' for details. 29518 29519 Do not define this macro if you do not define 29520 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 29521 `BITS_PER_WORD' bits wide is correct for your machine. 29522 29523 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 29524 A target hook which returns `true' if pseudos that have been 29525 assigned to registers of class RCLASS would likely be spilled 29526 because registers of RCLASS are needed for spill registers. 29527 29528 The default version of this target hook returns `true' if RCLASS 29529 has exactly one register and `false' otherwise. On most machines, 29530 this default should be used. For generally register-starved 29531 machines, such as i386, or machines with right register 29532 constraints, such as SH, this hook can be used to avoid excessive 29533 spilling. 29534 29535 This hook is also used by some of the global intra-procedural code 29536 transformations to throtle code motion, to avoid increasing 29537 register pressure. 29538 29539 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 29540 RCLASS, enum machine_mode MODE) 29541 A target hook returns the maximum number of consecutive registers 29542 of class RCLASS needed to hold a value of mode MODE. 29543 29544 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 29545 the value returned by `TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 29546 target hook should be the maximum value of `HARD_REGNO_NREGS 29547 (REGNO, MODE)' for all REGNO values in the class RCLASS. 29548 29549 This target hook helps control the handling of multiple-word values 29550 in the reload pass. 29551 29552 The default version of this target hook returns the size of MODE 29553 in words. 29554 29555 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 29556 A C expression for the maximum number of consecutive registers of 29557 class CLASS needed to hold a value of mode MODE. 29558 29559 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 29560 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be 29561 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all 29562 REGNO values in the class CLASS. 29563 29564 This macro helps control the handling of multiple-word values in 29565 the reload pass. 29566 29567 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 29568 If defined, a C expression that returns nonzero for a CLASS for 29569 which a change from mode FROM to mode TO is invalid. 29570 29571 For the example, loading 32-bit integer or floating-point objects 29572 into floating-point registers on the Alpha extends them to 64 bits. 29573 Therefore loading a 64-bit object and then storing it as a 32-bit 29574 object does not store the low-order 32 bits, as would be the case 29575 for a normal register. Therefore, `alpha.h' defines 29576 `CANNOT_CHANGE_MODE_CLASS' as below: 29577 29578 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 29579 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 29580 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 29581 29582 -- Target Hook: bool TARGET_LRA_P (void) 29583 A target hook which returns true if we use LRA instead of reload 29584 pass. It means that LRA was ported to the target. The default 29585 version of this target hook returns always false. 29586 29587 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 29588 A target hook which returns the register priority number to which 29589 the register HARD_REGNO belongs to. The bigger the number, the 29590 more preferable the hard register usage (when all other conditions 29591 are the same). This hook can be used to prefer some hard 29592 register over others in LRA. For example, some x86-64 register 29593 usage needs additional prefix which makes instructions longer. 29594 The hook can return lower priority number for such registers make 29595 them less favorable and as result making the generated code 29596 smaller. The default version of this target hook returns always 29597 zero. 29598 29599 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 29600 A target hook which returns true if an address with the same 29601 structure can have different maximal legitimate displacement. 29602 For example, the displacement can depend on memory mode or on 29603 operand combinations in the insn. The default version of this 29604 target hook returns always false. 29605 29606 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, enum 29607 MACHINE_MODE) 29608 This hook defines a class of registers which could be used for 29609 spilling pseudos of the given mode and class, or `NO_REGS' if 29610 only memory should be used. Not defining this hook is equivalent 29611 to returning `NO_REGS' for all inputs. 29612 29613 29614File: gccint.info, Node: Old Constraints, Next: Stack and Calling, Prev: Register Classes, Up: Target Macros 29615 2961617.9 Obsolete Macros for Defining Constraints 29617============================================= 29618 29619Machine-specific constraints can be defined with these macros instead 29620of the machine description constructs described in *note Define 29621Constraints::. This mechanism is obsolete. New ports should not use 29622it; old ports should convert to the new mechanism. 29623 29624 -- Macro: CONSTRAINT_LEN (CHAR, STR) 29625 For the constraint at the start of STR, which starts with the 29626 letter C, return the length. This allows you to have register 29627 class / constant / extra constraints that are longer than a single 29628 letter; you don't need to define this macro if you can do with 29629 single-letter constraints only. The definition of this macro 29630 should use DEFAULT_CONSTRAINT_LEN for all the characters that you 29631 don't want to handle specially. There are some sanity checks in 29632 genoutput.c that check the constraint lengths for the md file, so 29633 you can also use this macro to help you while you are 29634 transitioning from a byzantine single-letter-constraint scheme: 29635 when you return a negative length for a constraint you want to 29636 re-use, genoutput will complain about every instance where it is 29637 used in the md file. 29638 29639 -- Macro: REG_CLASS_FROM_LETTER (CHAR) 29640 A C expression which defines the machine-dependent operand 29641 constraint letters for register classes. If CHAR is such a 29642 letter, the value should be the register class corresponding to 29643 it. Otherwise, the value should be `NO_REGS'. The register 29644 letter `r', corresponding to class `GENERAL_REGS', will not be 29645 passed to this macro; you do not need to handle it. 29646 29647 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR) 29648 Like `REG_CLASS_FROM_LETTER', but you also get the constraint 29649 string passed in STR, so that you can use suffixes to distinguish 29650 between different variants. 29651 29652 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C) 29653 A C expression that defines the machine-dependent operand 29654 constraint letters (`I', `J', `K', ... `P') that specify 29655 particular ranges of integer values. If C is one of those 29656 letters, the expression should check that VALUE, an integer, is in 29657 the appropriate range and return 1 if so, 0 otherwise. If C is 29658 not one of those letters, the value should be 0 regardless of 29659 VALUE. 29660 29661 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 29662 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint 29663 string passed in STR, so that you can use suffixes to distinguish 29664 between different variants. 29665 29666 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C) 29667 A C expression that defines the machine-dependent operand 29668 constraint letters that specify particular ranges of 29669 `const_double' values (`G' or `H'). 29670 29671 If C is one of those letters, the expression should check that 29672 VALUE, an RTX of code `const_double', is in the appropriate range 29673 and return 1 if so, 0 otherwise. If C is not one of those 29674 letters, the value should be 0 regardless of VALUE. 29675 29676 `const_double' is used for all floating-point constants and for 29677 `DImode' fixed-point constants. A given letter can accept either 29678 or both kinds of values. It can use `GET_MODE' to distinguish 29679 between these kinds. 29680 29681 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 29682 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the 29683 constraint string passed in STR, so that you can use suffixes to 29684 distinguish between different variants. 29685 29686 -- Macro: EXTRA_CONSTRAINT (VALUE, C) 29687 A C expression that defines the optional machine-dependent 29688 constraint letters that can be used to segregate specific types of 29689 operands, usually memory references, for the target machine. Any 29690 letter that is not elsewhere defined and not matched by 29691 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used. 29692 Normally this macro will not be defined. 29693 29694 If it is required for a particular target machine, it should 29695 return 1 if VALUE corresponds to the operand type represented by 29696 the constraint letter C. If C is not defined as an extra 29697 constraint, the value returned should be 0 regardless of VALUE. 29698 29699 For example, on the ROMP, load instructions cannot have their 29700 output in r0 if the memory reference contains a symbolic address. 29701 Constraint letter `Q' is defined as representing a memory address 29702 that does _not_ contain a symbolic address. An alternative is 29703 specified with a `Q' constraint on the input and `r' on the 29704 output. The next alternative specifies `m' on the input and a 29705 register class that does not include r0 on the output. 29706 29707 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR) 29708 Like `EXTRA_CONSTRAINT', but you also get the constraint string 29709 passed in STR, so that you can use suffixes to distinguish between 29710 different variants. 29711 29712 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR) 29713 A C expression that defines the optional machine-dependent 29714 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT', 29715 that should be treated like memory constraints by the reload pass. 29716 29717 It should return 1 if the operand type represented by the 29718 constraint at the start of STR, the first letter of which is the 29719 letter C, comprises a subset of all memory references including 29720 all those whose address is simply a base register. This allows 29721 the reload pass to reload an operand, if it does not directly 29722 correspond to the operand type of C, by copying its address into a 29723 base register. 29724 29725 For example, on the S/390, some instructions do not accept 29726 arbitrary memory references, but only those that do not make use 29727 of an index register. The constraint letter `Q' is defined via 29728 `EXTRA_CONSTRAINT' as representing a memory address of this type. 29729 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q' 29730 constraint can handle any memory operand, because the reload pass 29731 knows it can be reloaded by copying the memory address into a base 29732 register if required. This is analogous to the way an `o' 29733 constraint can handle any memory operand. 29734 29735 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR) 29736 A C expression that defines the optional machine-dependent 29737 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' / 29738 `EXTRA_CONSTRAINT_STR', that should be treated like address 29739 constraints by the reload pass. 29740 29741 It should return 1 if the operand type represented by the 29742 constraint at the start of STR, which starts with the letter C, 29743 comprises a subset of all memory addresses including all those 29744 that consist of just a base register. This allows the reload pass 29745 to reload an operand, if it does not directly correspond to the 29746 operand type of STR, by copying it into a base register. 29747 29748 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be 29749 used with the `address_operand' predicate. It is treated 29750 analogously to the `p' constraint. 29751 29752 29753File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Old Constraints, Up: Target Macros 29754 2975517.10 Stack Layout and Calling Conventions 29756========================================== 29757 29758This describes the stack layout and calling conventions. 29759 29760* Menu: 29761 29762* Frame Layout:: 29763* Exception Handling:: 29764* Stack Checking:: 29765* Frame Registers:: 29766* Elimination:: 29767* Stack Arguments:: 29768* Register Arguments:: 29769* Scalar Return:: 29770* Aggregate Return:: 29771* Caller Saves:: 29772* Function Entry:: 29773* Profiling:: 29774* Tail Calls:: 29775* Stack Smashing Protection:: 29776 29777 29778File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 29779 2978017.10.1 Basic Stack Layout 29781-------------------------- 29782 29783Here is the basic stack layout. 29784 29785 -- Macro: STACK_GROWS_DOWNWARD 29786 Define this macro if pushing a word onto the stack moves the stack 29787 pointer to a smaller address. 29788 29789 When we say, "define this macro if ...", it means that the 29790 compiler checks this macro only with `#ifdef' so the precise 29791 definition used does not matter. 29792 29793 -- Macro: STACK_PUSH_CODE 29794 This macro defines the operation used when something is pushed on 29795 the stack. In RTL, a push operation will be `(set (mem 29796 (STACK_PUSH_CODE (reg sp))) ...)' 29797 29798 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'. 29799 Which of these is correct depends on the stack direction and on 29800 whether the stack pointer points to the last item on the stack or 29801 whether it points to the space for the next item on the stack. 29802 29803 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined, 29804 which is almost always right, and `PRE_INC' otherwise, which is 29805 often wrong. 29806 29807 -- Macro: FRAME_GROWS_DOWNWARD 29808 Define this macro to nonzero value if the addresses of local 29809 variable slots are at negative offsets from the frame pointer. 29810 29811 -- Macro: ARGS_GROW_DOWNWARD 29812 Define this macro if successive arguments to a function occupy 29813 decreasing addresses on the stack. 29814 29815 -- Macro: STARTING_FRAME_OFFSET 29816 Offset from the frame pointer to the first local variable slot to 29817 be allocated. 29818 29819 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by 29820 subtracting the first slot's length from `STARTING_FRAME_OFFSET'. 29821 Otherwise, it is found by adding the length of the first slot to 29822 the value `STARTING_FRAME_OFFSET'. 29823 29824 -- Macro: STACK_ALIGNMENT_NEEDED 29825 Define to zero to disable final alignment of the stack during 29826 reload. The nonzero default for this macro is suitable for most 29827 ports. 29828 29829 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there 29830 is a register save block following the local block that doesn't 29831 require alignment to `STACK_BOUNDARY', it may be beneficial to 29832 disable stack alignment and do it in the backend. 29833 29834 -- Macro: STACK_POINTER_OFFSET 29835 Offset from the stack pointer register to the first location at 29836 which outgoing arguments are placed. If not specified, the 29837 default value of zero is used. This is the proper value for most 29838 machines. 29839 29840 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 29841 the first location at which outgoing arguments are placed. 29842 29843 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 29844 Offset from the argument pointer register to the first argument's 29845 address. On some machines it may depend on the data type of the 29846 function. 29847 29848 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 29849 the first argument's address. 29850 29851 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 29852 Offset from the stack pointer register to an item dynamically 29853 allocated on the stack, e.g., by `alloca'. 29854 29855 The default value for this macro is `STACK_POINTER_OFFSET' plus the 29856 length of the outgoing arguments. The default is correct for most 29857 machines. See `function.c' for details. 29858 29859 -- Macro: INITIAL_FRAME_ADDRESS_RTX 29860 A C expression whose value is RTL representing the address of the 29861 initial stack frame. This address is passed to `RETURN_ADDR_RTX' 29862 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 29863 reasonable default value will be used. Define this macro in order 29864 to make frame pointer elimination work in the presence of 29865 `__builtin_frame_address (count)' and `__builtin_return_address 29866 (count)' for `count' not equal to zero. 29867 29868 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 29869 A C expression whose value is RTL representing the address in a 29870 stack frame where the pointer to the caller's frame is stored. 29871 Assume that FRAMEADDR is an RTL expression for the address of the 29872 stack frame itself. 29873 29874 If you don't define this macro, the default is to return the value 29875 of FRAMEADDR--that is, the stack frame address is also the address 29876 of the stack word that points to the previous frame. 29877 29878 -- Macro: SETUP_FRAME_ADDRESSES 29879 If defined, a C expression that produces the machine-specific code 29880 to setup the stack so that arbitrary frames can be accessed. For 29881 example, on the SPARC, we must flush all of the register windows 29882 to the stack before we can access arbitrary stack frames. You 29883 will seldom need to define this macro. 29884 29885 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 29886 This target hook should return an rtx that is used to store the 29887 address of the current frame into the built in `setjmp' buffer. 29888 The default value, `virtual_stack_vars_rtx', is correct for most 29889 machines. One reason you may need to define this target hook is if 29890 `hard_frame_pointer_rtx' is the appropriate value on your machine. 29891 29892 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 29893 A C expression whose value is RTL representing the value of the 29894 frame address for the current frame. FRAMEADDR is the frame 29895 pointer of the current frame. This is used for 29896 __builtin_frame_address. You need only define this macro if the 29897 frame address is not the same as the frame pointer. Most machines 29898 do not need to define it. 29899 29900 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 29901 A C expression whose value is RTL representing the value of the 29902 return address for the frame COUNT steps up from the current 29903 frame, after the prologue. FRAMEADDR is the frame pointer of the 29904 COUNT frame, or the frame pointer of the COUNT - 1 frame if 29905 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined. 29906 29907 The value of the expression must always be the correct address when 29908 COUNT is zero, but may be `NULL_RTX' if there is no way to 29909 determine the return address of other frames. 29910 29911 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 29912 Define this if the return address of a particular stack frame is 29913 accessed from the frame pointer of the previous stack frame. 29914 29915 -- Macro: INCOMING_RETURN_ADDR_RTX 29916 A C expression whose value is RTL representing the location of the 29917 incoming return address at the beginning of any function, before 29918 the prologue. This RTL is either a `REG', indicating that the 29919 return value is saved in `REG', or a `MEM' representing a location 29920 in the stack. 29921 29922 You only need to define this macro if you want to support call 29923 frame debugging information like that provided by DWARF 2. 29924 29925 If this RTL is a `REG', you should also define 29926 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'. 29927 29928 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 29929 A C expression whose value is an integer giving a DWARF 2 column 29930 number that may be used as an alternative return column. The 29931 column must not correspond to any gcc hard register (that is, it 29932 must not be in the range of `DWARF_FRAME_REGNUM'). 29933 29934 This macro can be useful if `DWARF_FRAME_RETURN_COLUMN' is set to a 29935 general register, but an alternative column needs to be used for 29936 signal frames. Some targets have also used different frame return 29937 columns over time. 29938 29939 -- Macro: DWARF_ZERO_REG 29940 A C expression whose value is an integer giving a DWARF 2 register 29941 number that is considered to always have the value zero. This 29942 should only be defined if the target has an architected zero 29943 register, and someone decided it was a good idea to use that 29944 register number to terminate the stack backtrace. New ports 29945 should avoid this. 29946 29947 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 29948 *LABEL, rtx PATTERN, int INDEX) 29949 This target hook allows the backend to emit frame-related insns 29950 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 29951 debugging info engine will invoke it on insns of the form 29952 (set (reg) (unspec [...] UNSPEC_INDEX)) 29953 and 29954 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 29955 to let the backend emit the call frame instructions. LABEL is the 29956 CFI label attached to the insn, PATTERN is the pattern of the insn 29957 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'. 29958 29959 -- Macro: INCOMING_FRAME_SP_OFFSET 29960 A C expression whose value is an integer giving the offset, in 29961 bytes, from the value of the stack pointer register to the top of 29962 the stack frame at the beginning of any function, before the 29963 prologue. The top of the frame is defined to be the value of the 29964 stack pointer in the previous frame, just before the call 29965 instruction. 29966 29967 You only need to define this macro if you want to support call 29968 frame debugging information like that provided by DWARF 2. 29969 29970 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 29971 A C expression whose value is an integer giving the offset, in 29972 bytes, from the argument pointer to the canonical frame address 29973 (cfa). The final value should coincide with that calculated by 29974 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 29975 during virtual register instantiation. 29976 29977 The default value for this macro is `FIRST_PARM_OFFSET (fundecl) + 29978 crtl->args.pretend_args_size', which is correct for most machines; 29979 in general, the arguments are found immediately before the stack 29980 frame. Note that this is not the case on some targets that save 29981 registers into the caller's frame, such as SPARC and rs6000, and 29982 so such targets need to define this macro. 29983 29984 You only need to define this macro if the default is incorrect, 29985 and you want to support call frame debugging information like that 29986 provided by DWARF 2. 29987 29988 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 29989 If defined, a C expression whose value is an integer giving the 29990 offset in bytes from the frame pointer to the canonical frame 29991 address (cfa). The final value should coincide with that 29992 calculated by `INCOMING_FRAME_SP_OFFSET'. 29993 29994 Normally the CFA is calculated as an offset from the argument 29995 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer 29996 is variable due to the ABI, this may not be possible. If this 29997 macro is defined, it implies that the virtual register 29998 instantiation should be based on the frame pointer instead of the 29999 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and 30000 `ARG_POINTER_CFA_OFFSET' should be defined. 30001 30002 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 30003 If defined, a C expression whose value is an integer giving the 30004 offset in bytes from the canonical frame address (cfa) to the 30005 frame base used in DWARF 2 debug information. The default is 30006 zero. A different value may reduce the size of debug information 30007 on some ports. 30008 30009 30010File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 30011 3001217.10.2 Exception Handling Support 30013---------------------------------- 30014 30015 -- Macro: EH_RETURN_DATA_REGNO (N) 30016 A C expression whose value is the Nth register number used for 30017 data by exception handlers, or `INVALID_REGNUM' if fewer than N 30018 registers are usable. 30019 30020 The exception handling library routines communicate with the 30021 exception handlers via a set of agreed upon registers. Ideally 30022 these registers should be call-clobbered; it is possible to use 30023 call-saved registers, but may negatively impact code size. The 30024 target must support at least 2 data registers, but should define 4 30025 if there are enough free registers. 30026 30027 You must define this macro if you want to support call frame 30028 exception handling like that provided by DWARF 2. 30029 30030 -- Macro: EH_RETURN_STACKADJ_RTX 30031 A C expression whose value is RTL representing a location in which 30032 to store a stack adjustment to be applied before function return. 30033 This is used to unwind the stack to an exception handler's call 30034 frame. It will be assigned zero on code paths that return 30035 normally. 30036 30037 Typically this is a call-clobbered hard register that is otherwise 30038 untouched by the epilogue, but could also be a stack slot. 30039 30040 Do not define this macro if the stack pointer is saved and restored 30041 by the regular prolog and epilog code in the call frame itself; in 30042 this case, the exception handling library routines will update the 30043 stack location to be restored in place. Otherwise, you must define 30044 this macro if you want to support call frame exception handling 30045 like that provided by DWARF 2. 30046 30047 -- Macro: EH_RETURN_HANDLER_RTX 30048 A C expression whose value is RTL representing a location in which 30049 to store the address of an exception handler to which we should 30050 return. It will not be assigned on code paths that return 30051 normally. 30052 30053 Typically this is the location in the call frame at which the 30054 normal return address is stored. For targets that return by 30055 popping an address off the stack, this might be a memory address 30056 just below the _target_ call frame rather than inside the current 30057 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already 30058 been assigned, so it may be used to calculate the location of the 30059 target call frame. 30060 30061 Some targets have more complex requirements than storing to an 30062 address calculable during initial code generation. In that case 30063 the `eh_return' instruction pattern should be used instead. 30064 30065 If you want to support call frame exception handling, you must 30066 define either this macro or the `eh_return' instruction pattern. 30067 30068 -- Macro: RETURN_ADDR_OFFSET 30069 If defined, an integer-valued C expression for which rtl will be 30070 generated to add it to the exception handler address before it is 30071 searched in the exception handling tables, and to subtract it 30072 again from the address before using it to return to the exception 30073 handler. 30074 30075 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 30076 This macro chooses the encoding of pointers embedded in the 30077 exception handling sections. If at all possible, this should be 30078 defined such that the exception handling section will not require 30079 dynamic relocations, and so may be read-only. 30080 30081 CODE is 0 for data, 1 for code labels, 2 for function pointers. 30082 GLOBAL is true if the symbol may be affected by dynamic 30083 relocations. The macro should return a combination of the 30084 `DW_EH_PE_*' defines as found in `dwarf2.h'. 30085 30086 If this macro is not defined, pointers will not be encoded but 30087 represented directly. 30088 30089 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 30090 ADDR, DONE) 30091 This macro allows the target to emit whatever special magic is 30092 required to represent the encoding chosen by 30093 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 30094 pc-relative and indirect encodings; this must be defined if the 30095 target uses text-relative or data-relative encodings. 30096 30097 This is a C statement that branches to DONE if the format was 30098 handled. ENCODING is the format chosen, SIZE is the number of 30099 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be 30100 emitted. 30101 30102 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 30103 This macro allows the target to add CPU and operating system 30104 specific code to the call-frame unwinder for use when there is no 30105 unwind data available. The most common reason to implement this 30106 macro is to unwind through signal frames. 30107 30108 This macro is called from `uw_frame_state_for' in `unwind-dw2.c', 30109 `unwind-dw2-xtensa.c' and `unwind-ia64.c'. CONTEXT is an 30110 `_Unwind_Context'; FS is an `_Unwind_FrameState'. Examine 30111 `context->ra' for the address of the code being executed and 30112 `context->cfa' for the stack pointer value. If the frame can be 30113 decoded, the register save addresses should be updated in FS and 30114 the macro should evaluate to `_URC_NO_REASON'. If the frame 30115 cannot be decoded, the macro should evaluate to 30116 `_URC_END_OF_STACK'. 30117 30118 For proper signal handling in Java this macro is accompanied by 30119 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h' 30120 headers. 30121 30122 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 30123 This macro allows the target to add operating system specific code 30124 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding 30125 directive, usually used for signal or interrupt frames. 30126 30127 This macro is called from `uw_update_context' in libgcc's 30128 `unwind-ia64.c'. CONTEXT is an `_Unwind_Context'; FS is an 30129 `_Unwind_FrameState'. Examine `fs->unwabi' for the abi and 30130 context in the `.unwabi' directive. If the `.unwabi' directive 30131 can be handled, the register save addresses should be updated in 30132 FS. 30133 30134 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 30135 A C expression that evaluates to true if the target requires unwind 30136 info to be given comdat linkage. Define it to be `1' if comdat 30137 linkage is necessary. The default is `0'. 30138 30139 30140File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 30141 3014217.10.3 Specifying How Stack Checking is Done 30143--------------------------------------------- 30144 30145GCC will check that stack references are within the boundaries of the 30146stack, if the option `-fstack-check' is specified, in one of three ways: 30147 30148 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC 30149 will assume that you have arranged for full stack checking to be 30150 done at appropriate places in the configuration files. GCC will 30151 not do other special processing. 30152 30153 2. If `STACK_CHECK_BUILTIN' is zero and the value of the 30154 `STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume 30155 that you have arranged for static stack checking (checking of the 30156 static stack frame of functions) to be done at appropriate places 30157 in the configuration files. GCC will only emit code to do dynamic 30158 stack checking (checking on dynamic stack allocations) using the 30159 third approach below. 30160 30161 3. If neither of the above are true, GCC will generate code to 30162 periodically "probe" the stack pointer using the values of the 30163 macros defined below. 30164 30165 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 30166defined, GCC will change its allocation strategy for large objects if 30167the option `-fstack-check' is specified: they will always be allocated 30168dynamically if their size exceeds `STACK_CHECK_MAX_VAR_SIZE' bytes. 30169 30170 -- Macro: STACK_CHECK_BUILTIN 30171 A nonzero value if stack checking is done by the configuration 30172 files in a machine-dependent manner. You should define this macro 30173 if stack checking is required by the ABI of your machine or if you 30174 would like to do stack checking in some more efficient way than 30175 the generic approach. The default value of this macro is zero. 30176 30177 -- Macro: STACK_CHECK_STATIC_BUILTIN 30178 A nonzero value if static stack checking is done by the 30179 configuration files in a machine-dependent manner. You should 30180 define this macro if you would like to do static stack checking in 30181 some more efficient way than the generic approach. The default 30182 value of this macro is zero. 30183 30184 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 30185 An integer specifying the interval at which GCC must generate 30186 stack probe instructions, defined as 2 raised to this integer. 30187 You will normally define this macro so that the interval be no 30188 larger than the size of the "guard pages" at the end of a stack 30189 area. The default value of 12 (4096-byte interval) is suitable 30190 for most systems. 30191 30192 -- Macro: STACK_CHECK_MOVING_SP 30193 An integer which is nonzero if GCC should move the stack pointer 30194 page by page when doing probes. This can be necessary on systems 30195 where the stack pointer contains the bottom address of the memory 30196 area accessible to the executing thread at any point in time. In 30197 this situation an alternate signal stack is required in order to 30198 be able to recover from a stack overflow. The default value of 30199 this macro is zero. 30200 30201 -- Macro: STACK_CHECK_PROTECT 30202 The number of bytes of stack needed to recover from a stack 30203 overflow, for languages where such a recovery is supported. The 30204 default value of 75 words with the `setjmp'/`longjmp'-based 30205 exception handling mechanism and 8192 bytes with other exception 30206 handling mechanisms should be adequate for most machines. 30207 30208 The following macros are relevant only if neither STACK_CHECK_BUILTIN 30209nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 30210in the opposite case. 30211 30212 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 30213 The maximum size of a stack frame, in bytes. GCC will generate 30214 probe instructions in non-leaf functions to ensure at least this 30215 many bytes of stack are available. If a stack frame is larger 30216 than this size, stack checking will not be reliable and GCC will 30217 issue a warning. The default is chosen so that GCC only generates 30218 one instruction on most systems. You should normally not change 30219 the default value of this macro. 30220 30221 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 30222 GCC uses this value to generate the above warning message. It 30223 represents the amount of fixed frame used by a function, not 30224 including space for any callee-saved registers, temporaries and 30225 user variables. You need only specify an upper bound for this 30226 amount and will normally use the default of four words. 30227 30228 -- Macro: STACK_CHECK_MAX_VAR_SIZE 30229 The maximum size, in bytes, of an object that GCC will place in the 30230 fixed area of the stack frame when the user specifies 30231 `-fstack-check'. GCC computed the default from the values of the 30232 above macros and you will normally not need to override that 30233 default. 30234 30235 30236File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 30237 3023817.10.4 Registers That Address the Stack Frame 30239---------------------------------------------- 30240 30241This discusses registers that address the stack frame. 30242 30243 -- Macro: STACK_POINTER_REGNUM 30244 The register number of the stack pointer register, which must also 30245 be a fixed register according to `FIXED_REGISTERS'. On most 30246 machines, the hardware determines which register this is. 30247 30248 -- Macro: FRAME_POINTER_REGNUM 30249 The register number of the frame pointer register, which is used to 30250 access automatic variables in the stack frame. On some machines, 30251 the hardware determines which register this is. On other 30252 machines, you can choose any register you wish for this purpose. 30253 30254 -- Macro: HARD_FRAME_POINTER_REGNUM 30255 On some machines the offset between the frame pointer and starting 30256 offset of the automatic variables is not known until after register 30257 allocation has been done (for example, because the saved registers 30258 are between these two locations). On those machines, define 30259 `FRAME_POINTER_REGNUM' the number of a special, fixed register to 30260 be used internally until the offset is known, and define 30261 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 30262 used for the frame pointer. 30263 30264 You should define this macro only in the very rare circumstances 30265 when it is not possible to calculate the offset between the frame 30266 pointer and the automatic variables until after register 30267 allocation has been completed. When this macro is defined, you 30268 must also indicate in your definition of `ELIMINABLE_REGS' how to 30269 eliminate `FRAME_POINTER_REGNUM' into either 30270 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. 30271 30272 Do not define this macro if it would be the same as 30273 `FRAME_POINTER_REGNUM'. 30274 30275 -- Macro: ARG_POINTER_REGNUM 30276 The register number of the arg pointer register, which is used to 30277 access the function's argument list. On some machines, this is 30278 the same as the frame pointer register. On some machines, the 30279 hardware determines which register this is. On other machines, 30280 you can choose any register you wish for this purpose. If this is 30281 not the same register as the frame pointer register, then you must 30282 mark it as a fixed register according to `FIXED_REGISTERS', or 30283 arrange to be able to eliminate it (*note Elimination::). 30284 30285 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 30286 Define this to a preprocessor constant that is nonzero if 30287 `hard_frame_pointer_rtx' and `frame_pointer_rtx' should be the 30288 same. The default definition is `(HARD_FRAME_POINTER_REGNUM == 30289 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 30290 definition is not suitable for use in preprocessor conditionals. 30291 30292 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 30293 Define this to a preprocessor constant that is nonzero if 30294 `hard_frame_pointer_rtx' and `arg_pointer_rtx' should be the same. 30295 The default definition is `(HARD_FRAME_POINTER_REGNUM == 30296 ARG_POINTER_REGNUM)'; you only need to define this macro if that 30297 definition is not suitable for use in preprocessor conditionals. 30298 30299 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 30300 The register number of the return address pointer register, which 30301 is used to access the current function's return address from the 30302 stack. On some machines, the return address is not at a fixed 30303 offset from the frame pointer or stack pointer or argument 30304 pointer. This register can be defined to point to the return 30305 address on the stack, and then be converted by `ELIMINABLE_REGS' 30306 into either the frame pointer or stack pointer. 30307 30308 Do not define this macro unless there is no other way to get the 30309 return address from the stack. 30310 30311 -- Macro: STATIC_CHAIN_REGNUM 30312 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 30313 Register numbers used for passing a function's static chain 30314 pointer. If register windows are used, the register number as 30315 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', 30316 while the register number as seen by the calling function is 30317 `STATIC_CHAIN_REGNUM'. If these registers are the same, 30318 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 30319 30320 The static chain register need not be a fixed register. 30321 30322 If the static chain is passed in memory, these macros should not be 30323 defined; instead, the `TARGET_STATIC_CHAIN' hook should be used. 30324 30325 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL, bool 30326 INCOMING_P) 30327 This hook replaces the use of `STATIC_CHAIN_REGNUM' et al for 30328 targets that may use different static chain locations for different 30329 nested functions. This may be required if the target has function 30330 attributes that affect the calling conventions of the function and 30331 those calling conventions use different static chain locations. 30332 30333 The default version of this hook uses `STATIC_CHAIN_REGNUM' et al. 30334 30335 If the static chain is passed in memory, this hook should be used 30336 to provide rtx giving `mem' expressions that denote where they are 30337 stored. Often the `mem' expression as seen by the caller will be 30338 at an offset from the stack pointer and the `mem' expression as 30339 seen by the callee will be at an offset from the frame pointer. The 30340 variables `stack_pointer_rtx', `frame_pointer_rtx', and 30341 `arg_pointer_rtx' will have been initialized and should be used to 30342 refer to those items. 30343 30344 -- Macro: DWARF_FRAME_REGISTERS 30345 This macro specifies the maximum number of hard registers that can 30346 be saved in a call frame. This is used to size data structures 30347 used in DWARF2 exception handling. 30348 30349 Prior to GCC 3.0, this macro was needed in order to establish a 30350 stable exception handling ABI in the face of adding new hard 30351 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 30352 insulated from changes in the number of hard registers. 30353 Nevertheless, this macro can still be used to reduce the runtime 30354 memory requirements of the exception handling routines, which can 30355 be substantial if the ISA contains a lot of registers that are not 30356 call-saved. 30357 30358 If this macro is not defined, it defaults to 30359 `FIRST_PSEUDO_REGISTER'. 30360 30361 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 30362 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided 30363 for backward compatibility in pre GCC 3.0 compiled code. 30364 30365 If this macro is not defined, it defaults to 30366 `DWARF_FRAME_REGISTERS'. 30367 30368 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 30369 Define this macro if the target's representation for dwarf 30370 registers is different than the internal representation for unwind 30371 column. Given a dwarf register, this macro should return the 30372 internal unwind column number to use instead. 30373 30374 See the PowerPC's SPE target for an example. 30375 30376 -- Macro: DWARF_FRAME_REGNUM (REGNO) 30377 Define this macro if the target's representation for dwarf 30378 registers used in .eh_frame or .debug_frame is different from that 30379 used in other debug info sections. Given a GCC hard register 30380 number, this macro should return the .eh_frame register number. 30381 The default is `DBX_REGISTER_NUMBER (REGNO)'. 30382 30383 30384 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 30385 Define this macro to map register numbers held in the call frame 30386 info that GCC has collected using `DWARF_FRAME_REGNUM' to those 30387 that should be output in .debug_frame (`FOR_EH' is zero) and 30388 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'. 30389 30390 30391 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 30392 Define this macro if the target stores register values as 30393 `_Unwind_Word' type in unwind context. It should be defined if 30394 target register size is larger than the size of `void *'. The 30395 default is to store register values as `void *' type. 30396 30397 30398 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 30399 Define this macro to be 1 if the target always uses extended unwind 30400 context with version, args_size and by_value fields. If it is 30401 undefined, it will be defined to 1 when 30402 `REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 30403 30404 30405 30406File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 30407 3040817.10.5 Eliminating Frame Pointer and Arg Pointer 30409------------------------------------------------- 30410 30411This is about eliminating the frame pointer and arg pointer. 30412 30413 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 30414 This target hook should return `true' if a function must have and 30415 use a frame pointer. This target hook is called in the reload 30416 pass. If its return value is `true' the function will have a 30417 frame pointer. 30418 30419 This target hook can in principle examine the current function and 30420 decide according to the facts, but on most machines the constant 30421 `false' or the constant `true' suffices. Use `false' when the 30422 machine allows code to be generated with no frame pointer, and 30423 doing so saves some time or space. Use `true' when there is no 30424 possible advantage to avoiding a frame pointer. 30425 30426 In certain cases, the compiler does not know how to produce valid 30427 code without a frame pointer. The compiler recognizes those cases 30428 and automatically gives the function a frame pointer regardless of 30429 what `TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to 30430 worry about them. 30431 30432 In a function that does not require a frame pointer, the frame 30433 pointer register can be allocated for ordinary usage, unless you 30434 mark it as a fixed register. See `FIXED_REGISTERS' for more 30435 information. 30436 30437 Default return value is `false'. 30438 30439 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 30440 A C statement to store in the variable DEPTH-VAR the difference 30441 between the frame pointer and the stack pointer values immediately 30442 after the function prologue. The value would be computed from 30443 information such as the result of `get_frame_size ()' and the 30444 tables of registers `regs_ever_live' and `call_used_regs'. 30445 30446 If `ELIMINABLE_REGS' is defined, this macro will be not be used and 30447 need not be defined. Otherwise, it must be defined even if 30448 `TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case, 30449 you may set DEPTH-VAR to anything. 30450 30451 -- Macro: ELIMINABLE_REGS 30452 If defined, this macro specifies a table of register pairs used to 30453 eliminate unneeded registers that point into the stack frame. If 30454 it is not defined, the only elimination attempted by the compiler 30455 is to replace references to the frame pointer with references to 30456 the stack pointer. 30457 30458 The definition of this macro is a list of structure 30459 initializations, each of which specifies an original and 30460 replacement register. 30461 30462 On some machines, the position of the argument pointer is not 30463 known until the compilation is completed. In such a case, a 30464 separate hard register must be used for the argument pointer. 30465 This register can be eliminated by replacing it with either the 30466 frame pointer or the argument pointer, depending on whether or not 30467 the frame pointer has been eliminated. 30468 30469 In this case, you might specify: 30470 #define ELIMINABLE_REGS \ 30471 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 30472 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 30473 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 30474 30475 Note that the elimination of the argument pointer with the stack 30476 pointer is specified first since that is the preferred elimination. 30477 30478 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 30479 int TO_REG) 30480 This target hook should returns `true' if the compiler is allowed 30481 to try to replace register number FROM_REG with register number 30482 TO_REG. This target hook need only be defined if `ELIMINABLE_REGS' 30483 is defined, and will usually be `true', since most of the cases 30484 preventing register elimination are things that the compiler 30485 already knows about. 30486 30487 Default return value is `true'. 30488 30489 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 30490 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 30491 specifies the initial difference between the specified pair of 30492 registers. This macro must be defined if `ELIMINABLE_REGS' is 30493 defined. 30494 30495 30496File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 30497 3049817.10.6 Passing Function Arguments on the Stack 30499----------------------------------------------- 30500 30501The macros in this section control how arguments are passed on the 30502stack. See the following section for other macros that control passing 30503certain arguments in registers. 30504 30505 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 30506 This target hook returns `true' if an argument declared in a 30507 prototype as an integral type smaller than `int' should actually be 30508 passed as an `int'. In addition to avoiding errors in certain 30509 cases of mismatch, it also makes for better code on certain 30510 machines. The default is to not promote prototypes. 30511 30512 -- Macro: PUSH_ARGS 30513 A C expression. If nonzero, push insns will be used to pass 30514 outgoing arguments. If the target machine does not have a push 30515 instruction, set it to zero. That directs GCC to use an alternate 30516 strategy: to allocate the entire argument block and then store the 30517 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING' 30518 must be defined too. 30519 30520 -- Macro: PUSH_ARGS_REVERSED 30521 A C expression. If nonzero, function arguments will be evaluated 30522 from last to first, rather than from first to last. If this macro 30523 is not defined, it defaults to `PUSH_ARGS' on targets where the 30524 stack and args grow in opposite directions, and 0 otherwise. 30525 30526 -- Macro: PUSH_ROUNDING (NPUSHED) 30527 A C expression that is the number of bytes actually pushed onto the 30528 stack when an instruction attempts to push NPUSHED bytes. 30529 30530 On some machines, the definition 30531 30532 #define PUSH_ROUNDING(BYTES) (BYTES) 30533 30534 will suffice. But on other machines, instructions that appear to 30535 push one byte actually push two bytes in an attempt to maintain 30536 alignment. Then the definition should be 30537 30538 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 30539 30540 If the value of this macro has a type, it should be an unsigned 30541 type. 30542 30543 -- Macro: ACCUMULATE_OUTGOING_ARGS 30544 A C expression. If nonzero, the maximum amount of space required 30545 for outgoing arguments will be computed and placed into 30546 `crtl->outgoing_args_size'. No space will be pushed onto the 30547 stack for each call; instead, the function prologue should 30548 increase the stack frame size by this amount. 30549 30550 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not 30551 proper. 30552 30553 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 30554 Define this macro if functions should assume that stack space has 30555 been allocated for arguments even when their values are passed in 30556 registers. 30557 30558 The value of this macro is the size, in bytes, of the area 30559 reserved for arguments passed in registers for the function 30560 represented by FNDECL, which can be zero if GCC is calling a 30561 library function. The argument FNDECL can be the FUNCTION_DECL, 30562 or the type itself of the function. 30563 30564 This space can be allocated by the caller, or be a part of the 30565 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says 30566 which. 30567 30568 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 30569 Like `REG_PARM_STACK_SPACE', but for incoming register arguments. 30570 Define this macro if space guaranteed when compiling a function 30571 body is different to space required when making a call, a 30572 situation that can arise with K&R style function definitions. 30573 30574 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 30575 Define this to a nonzero value if it is the responsibility of the 30576 caller to allocate the area reserved for arguments passed in 30577 registers when calling a function of FNTYPE. FNTYPE may be NULL 30578 if the function called is a library function. 30579 30580 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 30581 whether the space for these arguments counts in the value of 30582 `crtl->outgoing_args_size'. 30583 30584 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 30585 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the 30586 stack parameters don't skip the area specified by it. 30587 30588 Normally, when a parameter is not passed in registers, it is 30589 placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 30590 Defining this macro suppresses this behavior and causes the 30591 parameter to be passed on the stack in its natural location. 30592 30593 -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 30594 FUNTYPE, int SIZE) 30595 This target hook returns the number of bytes of its own arguments 30596 that a function pops on returning, or 0 if the function pops no 30597 arguments and the caller must therefore pop them all after the 30598 function returns. 30599 30600 FUNDECL is a C variable whose value is a tree node that describes 30601 the function in question. Normally it is a node of type 30602 `FUNCTION_DECL' that describes the declaration of the function. 30603 From this you can obtain the `DECL_ATTRIBUTES' of the function. 30604 30605 FUNTYPE is a C variable whose value is a tree node that describes 30606 the function in question. Normally it is a node of type 30607 `FUNCTION_TYPE' that describes the data type of the function. 30608 From this it is possible to obtain the data types of the value and 30609 arguments (if known). 30610 30611 When a call to a library function is being considered, FUNDECL 30612 will contain an identifier node for the library function. Thus, if 30613 you need to distinguish among various library functions, you can 30614 do so by their names. Note that "library function" in this 30615 context means a function used to perform arithmetic, whose name is 30616 known specially in the compiler and was not mentioned in the C 30617 code being compiled. 30618 30619 SIZE is the number of bytes of arguments passed on the stack. If 30620 a variable number of bytes is passed, it is zero, and argument 30621 popping will always be the responsibility of the calling function. 30622 30623 On the VAX, all functions always pop their arguments, so the 30624 definition of this macro is SIZE. On the 68000, using the standard 30625 calling convention, no functions pop their arguments, so the value 30626 of the macro is always 0 in this case. But an alternative calling 30627 convention is available in which functions that take a fixed 30628 number of arguments pop them but other functions (such as 30629 `printf') pop nothing (the caller pops all). When this convention 30630 is in use, FUNTYPE is examined to determine whether a function 30631 takes a fixed number of arguments. 30632 30633 -- Macro: CALL_POPS_ARGS (CUM) 30634 A C expression that should indicate the number of bytes a call 30635 sequence pops off the stack. It is added to the value of 30636 `RETURN_POPS_ARGS' when compiling a function call. 30637 30638 CUM is the variable in which all arguments to the called function 30639 have been accumulated. 30640 30641 On certain architectures, such as the SH5, a call trampoline is 30642 used that pops certain registers off the stack, depending on the 30643 arguments that have been passed to the function. Since this is a 30644 property of the call site, not of the called function, 30645 `RETURN_POPS_ARGS' is not appropriate. 30646 30647 30648File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 30649 3065017.10.7 Passing Arguments in Registers 30651-------------------------------------- 30652 30653This section describes the macros which let you control how various 30654types of arguments are passed in registers or how they are arranged in 30655the stack. 30656 30657 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, enum 30658 machine_mode MODE, const_tree TYPE, bool NAMED) 30659 Return an RTX indicating whether a function argument is passed in a 30660 register and if so, which register. 30661 30662 The arguments are CA, which summarizes all the previous arguments; 30663 MODE, the machine mode of the argument; TYPE, the data type of the 30664 argument as a tree node or 0 if that is not known (which happens 30665 for C support library functions); and NAMED, which is `true' for 30666 an ordinary argument and `false' for nameless arguments that 30667 correspond to `...' in the called function's prototype. TYPE can 30668 be an incomplete type if a syntax error has previously occurred. 30669 30670 The return value is usually either a `reg' RTX for the hard 30671 register in which to pass the argument, or zero to pass the 30672 argument on the stack. 30673 30674 The value of the expression can also be a `parallel' RTX. This is 30675 used when an argument is passed in multiple locations. The mode 30676 of the `parallel' should be the mode of the entire argument. The 30677 `parallel' holds any number of `expr_list' pairs; each one 30678 describes where part of the argument is passed. In each 30679 `expr_list' the first operand must be a `reg' RTX for the hard 30680 register in which to pass this part of the argument, and the mode 30681 of the register RTX indicates how large this part of the argument 30682 is. The second operand of the `expr_list' is a `const_int' which 30683 gives the offset in bytes into the entire argument of where this 30684 part starts. As a special exception the first `expr_list' in the 30685 `parallel' RTX may have a first operand of zero. This indicates 30686 that the entire argument is also stored on the stack. 30687 30688 The last time this hook is called, it is called with `MODE == 30689 VOIDmode', and its result is passed to the `call' or `call_value' 30690 pattern as operands 2 and 3 respectively. 30691 30692 The usual way to make the ISO library `stdarg.h' work on a machine 30693 where some arguments are usually passed in registers, is to cause 30694 nameless arguments to be passed on the stack instead. This is 30695 done by making `TARGET_FUNCTION_ARG' return 0 whenever NAMED is 30696 `false'. 30697 30698 You may use the hook `targetm.calls.must_pass_in_stack' in the 30699 definition of this macro to determine if this argument is of a 30700 type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 30701 is not defined and `TARGET_FUNCTION_ARG' returns nonzero for such 30702 an argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 30703 defined, the argument will be computed in the stack and then 30704 loaded into a register. 30705 30706 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode 30707 MODE, const_tree TYPE) 30708 This target hook should return `true' if we should not pass TYPE 30709 solely in registers. The file `expr.h' defines a definition that 30710 is usually appropriate, refer to `expr.h' for additional 30711 documentation. 30712 30713 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t 30714 CA, enum machine_mode MODE, const_tree TYPE, bool NAMED) 30715 Define this hook if the target machine has "register windows", so 30716 that the register in which a function sees an arguments is not 30717 necessarily the same as the one in which the caller passed the 30718 argument. 30719 30720 For such machines, `TARGET_FUNCTION_ARG' computes the register in 30721 which the caller passes the value, and 30722 `TARGET_FUNCTION_INCOMING_ARG' should be defined in a similar 30723 fashion to tell the function being called where the arguments will 30724 arrive. 30725 30726 If `TARGET_FUNCTION_INCOMING_ARG' is not defined, 30727 `TARGET_FUNCTION_ARG' serves both purposes. 30728 30729 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 30730 enum machine_mode MODE, tree TYPE, bool NAMED) 30731 This target hook returns the number of bytes at the beginning of an 30732 argument that must be put in registers. The value must be zero for 30733 arguments that are passed entirely in registers or that are 30734 entirely pushed on the stack. 30735 30736 On some machines, certain arguments must be passed partially in 30737 registers and partially in memory. On these machines, typically 30738 the first few words of arguments are passed in registers, and the 30739 rest on the stack. If a multi-word argument (a `double' or a 30740 structure) crosses that boundary, its first few words must be 30741 passed in registers and the rest must be pushed. This macro tells 30742 the compiler when this occurs, and how many bytes should go in 30743 registers. 30744 30745 `TARGET_FUNCTION_ARG' for these arguments should return the first 30746 register to be used by the caller for this argument; likewise 30747 `TARGET_FUNCTION_INCOMING_ARG', for the called function. 30748 30749 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 30750 enum machine_mode MODE, const_tree TYPE, bool NAMED) 30751 This target hook should return `true' if an argument at the 30752 position indicated by CUM should be passed by reference. This 30753 predicate is queried after target independent reasons for being 30754 passed by reference, such as `TREE_ADDRESSABLE (type)'. 30755 30756 If the hook returns true, a copy of that argument is made in 30757 memory and a pointer to the argument is passed instead of the 30758 argument itself. The pointer is passed in whatever way is 30759 appropriate for passing a pointer to that type. 30760 30761 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, enum 30762 machine_mode MODE, const_tree TYPE, bool NAMED) 30763 The function argument described by the parameters to this hook is 30764 known to be passed by reference. The hook should return true if 30765 the function argument should be copied by the callee instead of 30766 copied by the caller. 30767 30768 For any argument for which the hook returns true, if it can be 30769 determined that the argument is not modified, then a copy need not 30770 be generated. 30771 30772 The default version of this hook always returns false. 30773 30774 -- Macro: CUMULATIVE_ARGS 30775 A C type for declaring a variable that is used as the first 30776 argument of `TARGET_FUNCTION_ARG' and other related values. For 30777 some target machines, the type `int' suffices and can hold the 30778 number of bytes of argument so far. 30779 30780 There is no need to record in `CUMULATIVE_ARGS' anything about the 30781 arguments that have been passed on the stack. The compiler has 30782 other variables to keep track of that. For target machines on 30783 which all arguments are passed on the stack, there is no need to 30784 store anything in `CUMULATIVE_ARGS'; however, the data structure 30785 must exist and should not be empty, so use `int'. 30786 30787 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 30788 If defined, this macro is called before generating any code for a 30789 function, but after the CFUN descriptor for the function has been 30790 created. The back end may use this macro to update CFUN to 30791 reflect an ABI other than that which would normally be used by 30792 default. If the compiler is generating code for a 30793 compiler-generated function, FNDECL may be `NULL'. 30794 30795 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 30796 N_NAMED_ARGS) 30797 A C statement (sans semicolon) for initializing the variable CUM 30798 for the state at the beginning of the argument list. The variable 30799 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 30800 for the data type of the function which will receive the args, or 30801 0 if the args are to a compiler support library function. For 30802 direct calls that are not libcalls, FNDECL contain the declaration 30803 node of the function. FNDECL is also set when 30804 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function 30805 being compiled. N_NAMED_ARGS is set to the number of named 30806 arguments, including a structure return address if it is passed as 30807 a parameter, when making a call. When processing incoming 30808 arguments, N_NAMED_ARGS is set to -1. 30809 30810 When processing a call to a compiler support library function, 30811 LIBNAME identifies which one. It is a `symbol_ref' rtx which 30812 contains the name of the function, as a string. LIBNAME is 0 when 30813 an ordinary C function call is being processed. Thus, each time 30814 this macro is called, either LIBNAME or FNTYPE is nonzero, but 30815 never both of them at once. 30816 30817 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 30818 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, 30819 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'. 30820 INDIRECT would always be zero, too. If this macro is not defined, 30821 `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 30822 30823 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 30824 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 30825 finding the arguments for the function being compiled. If this 30826 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 30827 30828 The value passed for LIBNAME is always 0, since library routines 30829 with special calling conventions are never compiled with GCC. The 30830 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'. 30831 30832 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t 30833 CA, enum machine_mode MODE, const_tree TYPE, bool NAMED) 30834 This hook updates the summarizer variable pointed to by CA to 30835 advance past an argument in the argument list. The values MODE, 30836 TYPE and NAMED describe that argument. Once this is done, the 30837 variable CUM is suitable for analyzing the _following_ argument 30838 with `TARGET_FUNCTION_ARG', etc. 30839 30840 This hook need not do anything if the argument in question was 30841 passed on the stack. The compiler knows how to track the amount 30842 of stack space used for arguments without any special help. 30843 30844 -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE) 30845 If defined, a C expression that is the number of bytes to add to 30846 the offset of the argument passed in memory. This is needed for 30847 the SPU, which passes `char' and `short' arguments in the preferred 30848 slot that is in the middle of the quad word instead of starting at 30849 the top. 30850 30851 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 30852 If defined, a C expression which determines whether, and in which 30853 direction, to pad out an argument with extra space. The value 30854 should be of type `enum direction': either `upward' to pad above 30855 the argument, `downward' to pad below, or `none' to inhibit 30856 padding. 30857 30858 The _amount_ of padding is not controlled by this macro, but by the 30859 target hook `TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always 30860 just enough to reach the next multiple of that boundary. 30861 30862 This macro has a default definition which is right for most 30863 systems. For little-endian machines, the default is to pad 30864 upward. For big-endian machines, the default is to pad downward 30865 for an argument of constant size shorter than an `int', and upward 30866 otherwise. 30867 30868 -- Macro: PAD_VARARGS_DOWN 30869 If defined, a C expression which determines whether the default 30870 implementation of va_arg will attempt to pad down before reading 30871 the next argument, if that argument is smaller than its aligned 30872 space as controlled by `PARM_BOUNDARY'. If this macro is not 30873 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN' 30874 is true. 30875 30876 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 30877 Specify padding for the last element of a block move between 30878 registers and memory. FIRST is nonzero if this is the only 30879 element. Defining this macro allows better control of register 30880 function parameters on big-endian machines, without using 30881 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test 30882 padding and mode of types in registers, as there is no longer a 30883 "wrong" part of a register; For example, a three byte aggregate 30884 may be passed in the high part of a register if so required. 30885 30886 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (enum 30887 machine_mode MODE, const_tree TYPE) 30888 This hook returns the alignment boundary, in bits, of an argument 30889 with the specified mode and type. The default hook returns 30890 `PARM_BOUNDARY' for all arguments. 30891 30892 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY (enum 30893 machine_mode MODE, const_tree TYPE) 30894 Normally, the size of an argument is rounded up to `PARM_BOUNDARY', 30895 which is the default value for this hook. You can define this 30896 hook to return a different value if an argument size must be 30897 rounded to a larger value. 30898 30899 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 30900 A C expression that is nonzero if REGNO is the number of a hard 30901 register in which function arguments are sometimes passed. This 30902 does _not_ include implicit arguments such as the static chain and 30903 the structure-value address. On many machines, no registers can be 30904 used for this purpose since all function arguments are pushed on 30905 the stack. 30906 30907 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 30908 This hook should return true if parameter of type TYPE are passed 30909 as two scalar parameters. By default, GCC will attempt to pack 30910 complex arguments into the target's word size. Some ABIs require 30911 complex arguments to be split and treated as their individual 30912 components. For example, on AIX64, complex floats should be 30913 passed in a pair of floating point registers, even though a 30914 complex float would fit in one 64-bit floating point register. 30915 30916 The default value of this hook is `NULL', which is treated as 30917 always false. 30918 30919 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 30920 This hook returns a type node for `va_list' for the target. The 30921 default version of the hook returns `void*'. 30922 30923 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char 30924 **PNAME, tree *PTREE) 30925 This target hook is used in function `c_common_nodes_and_builtins' 30926 to iterate through the target specific builtin types for va_list. 30927 The variable IDX is used as iterator. PNAME has to be a pointer to 30928 a `const char *' and PTREE a pointer to a `tree' typed variable. 30929 The arguments PNAME and PTREE are used to store the result of this 30930 macro and are set to the name of the va_list builtin type and its 30931 internal type. If the return value of this macro is zero, then 30932 there is no more element. Otherwise the IDX should be increased 30933 for the next call of this macro to iterate through all types. 30934 30935 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 30936 This hook returns the va_list type of the calling convention 30937 specified by FNDECL. The default version of this hook returns 30938 `va_list_type_node'. 30939 30940 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 30941 This hook returns the va_list type of the calling convention 30942 specified by the type of TYPE. If TYPE is not a valid va_list 30943 type, it returns `NULL_TREE'. 30944 30945 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 30946 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 30947 This hook performs target-specific gimplification of 30948 `VA_ARG_EXPR'. The first two parameters correspond to the 30949 arguments to `va_arg'; the latter two are as in 30950 `gimplify.c:gimplify_expr'. 30951 30952 -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE) 30953 Define this to return nonzero if the port can handle pointers with 30954 machine mode MODE. The default version of this hook returns true 30955 for both `ptr_mode' and `Pmode'. 30956 30957 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref_s *REF) 30958 Define this to return nonzero if the memory reference REF may 30959 alias with the system C library errno location. The default 30960 version of this hook assumes the system C library errno location 30961 is either a declaration of type int or accessed by dereferencing 30962 a pointer to int. 30963 30964 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode 30965 MODE) 30966 Define this to return nonzero if the port is prepared to handle 30967 insns involving scalar mode MODE. For a scalar mode to be 30968 considered supported, all the basic arithmetic and comparisons 30969 must work. 30970 30971 The default version of this hook returns true for any mode 30972 required to handle the basic C types (as defined by the port). 30973 Included here are the double-word arithmetic supported by the code 30974 in `optabs.c'. 30975 30976 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode 30977 MODE) 30978 Define this to return nonzero if the port is prepared to handle 30979 insns involving vector mode MODE. At the very least, it must have 30980 move patterns for this mode. 30981 30982 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (enum machine_mode 30983 MODE, unsigned HOST_WIDE_INT NELEMS) 30984 Return true if GCC should try to use a scalar mode to store an 30985 array of NELEMS elements, given that each element has mode MODE. 30986 Returning true here overrides the usual `MAX_FIXED_MODE' limit and 30987 allows GCC to use any defined integer mode. 30988 30989 One use of this hook is to support vector load and store operations 30990 that operate on several homogeneous vectors. For example, ARM NEON 30991 has operations like: 30992 30993 int8x8x3_t vld3_s8 (const int8_t *) 30994 30995 where the return type is defined as: 30996 30997 typedef struct int8x8x3_t 30998 { 30999 int8x8_t val[3]; 31000 } int8x8x3_t; 31001 31002 If this hook allows `val' to have a scalar mode, then `int8x8x3_t' 31003 can have the same mode. GCC can then store `int8x8x3_t's in 31004 registers rather than forcing them onto the stack. 31005 31006 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P (enum 31007 machine_mode MODE) 31008 Define this to return nonzero for machine modes for which the port 31009 has small register classes. If this target hook returns nonzero 31010 for a given MODE, the compiler will try to minimize the lifetime 31011 of registers in MODE. The hook may be called with `VOIDmode' as 31012 argument. In this case, the hook is expected to return nonzero if 31013 it returns nonzero for any mode. 31014 31015 On some machines, it is risky to let hard registers live across 31016 arbitrary insns. Typically, these machines have instructions that 31017 require values to be in specific registers (like an accumulator), 31018 and reload will fail if the required hard register is used for 31019 another purpose across such an insn. 31020 31021 Passes before reload do not know which hard registers will be used 31022 in an instruction, but the machine modes of the registers set or 31023 used in the instruction are already known. And for some machines, 31024 register classes are small for, say, integer registers but not for 31025 floating point registers. For example, the AMD x86-64 31026 architecture requires specific registers for the legacy x86 31027 integer instructions, but there are many SSE registers for 31028 floating point operations. On such targets, a good strategy may 31029 be to return nonzero from this hook for `INTEGRAL_MODE_P' machine 31030 modes but zero for the SSE register classes. 31031 31032 The default version of this hook returns false for any mode. It 31033 is always safe to redefine this hook to return with a nonzero 31034 value. But if you unnecessarily define it, you will reduce the 31035 amount of optimizations that can be performed in some cases. If 31036 you do not define this hook to return a nonzero value when it is 31037 required, the compiler will run out of spill registers and print a 31038 fatal error message. 31039 31040 31041File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 31042 3104317.10.8 How Scalar Function Values Are Returned 31044----------------------------------------------- 31045 31046This section discusses the macros that control returning scalars as 31047values--values that can fit in registers. 31048 31049 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 31050 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 31051 Define this to return an RTX representing the place where a 31052 function returns or receives a value of data type RET_TYPE, a tree 31053 node representing a data type. FN_DECL_OR_TYPE is a tree node 31054 representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function 31055 being called. If OUTGOING is false, the hook should compute the 31056 register in which the caller will see the return value. 31057 Otherwise, the hook should return an RTX representing the place 31058 where a function returns a value. 31059 31060 On many machines, only `TYPE_MODE (RET_TYPE)' is relevant. 31061 (Actually, on most machines, scalar values are returned in the same 31062 place regardless of mode.) The value of the expression is usually 31063 a `reg' RTX for the hard register where the return value is stored. 31064 The value can also be a `parallel' RTX, if the return value is in 31065 multiple places. See `TARGET_FUNCTION_ARG' for an explanation of 31066 the `parallel' form. Note that the callee will populate every 31067 location specified in the `parallel', but if the first element of 31068 the `parallel' contains the whole return value, callers will use 31069 that element as the canonical location and ignore the others. The 31070 m68k port uses this type of `parallel' to return pointers in both 31071 `%a0' (the canonical location) and `%d0'. 31072 31073 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 31074 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is 31075 a scalar type. 31076 31077 If the precise function being called is known, FUNC is a tree node 31078 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 31079 makes it possible to use a different value-returning convention 31080 for specific functions when all their calls are known. 31081 31082 Some target machines have "register windows" so that the register 31083 in which a function returns its value is not the same as the one 31084 in which the caller sees the value. For such machines, you should 31085 return different RTX depending on OUTGOING. 31086 31087 `TARGET_FUNCTION_VALUE' is not used for return values with 31088 aggregate data types, because these are returned in another way. 31089 See `TARGET_STRUCT_VALUE_RTX' and related macros, below. 31090 31091 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 31092 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 31093 new target instead. 31094 31095 -- Macro: LIBCALL_VALUE (MODE) 31096 A C expression to create an RTX representing the place where a 31097 library function returns a value of mode MODE. 31098 31099 Note that "library function" in this context means a compiler 31100 support routine, used to perform arithmetic, whose name is known 31101 specially by the compiler and was not mentioned in the C code being 31102 compiled. 31103 31104 -- Target Hook: rtx TARGET_LIBCALL_VALUE (enum machine_mode MODE, 31105 const_rtx FUN) 31106 Define this hook if the back-end needs to know the name of the 31107 libcall function in order to determine where the result should be 31108 returned. 31109 31110 The mode of the result is given by MODE and the name of the called 31111 library function is given by FUN. The hook should return an RTX 31112 representing the place where the library function result will be 31113 returned. 31114 31115 If this hook is not defined, then LIBCALL_VALUE will be used. 31116 31117 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 31118 A C expression that is nonzero if REGNO is the number of a hard 31119 register in which the values of called function may come back. 31120 31121 A register whose use for returning values is limited to serving as 31122 the second of a pair (for a value of type `double', say) need not 31123 be recognized by this macro. So for most machines, this definition 31124 suffices: 31125 31126 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 31127 31128 If the machine has register windows, so that the caller and the 31129 called function use different registers for the return value, this 31130 macro should recognize only the caller's register numbers. 31131 31132 This macro has been deprecated. Use 31133 `TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 31134 31135 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 31136 REGNO) 31137 A target hook that return `true' if REGNO is the number of a hard 31138 register in which the values of called function may come back. 31139 31140 A register whose use for returning values is limited to serving as 31141 the second of a pair (for a value of type `double', say) need not 31142 be recognized by this target hook. 31143 31144 If the machine has register windows, so that the caller and the 31145 called function use different registers for the return value, this 31146 target hook should recognize only the caller's register numbers. 31147 31148 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 31149 used. 31150 31151 -- Macro: APPLY_RESULT_SIZE 31152 Define this macro if `untyped_call' and `untyped_return' need more 31153 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and 31154 restoring an arbitrary return value. 31155 31156 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 31157 This hook should return true if values of type TYPE are returned 31158 at the most significant end of a register (in other words, if they 31159 are padded at the least significant end). You can assume that TYPE 31160 is returned in a register; the caller is required to check this. 31161 31162 Note that the register provided by `TARGET_FUNCTION_VALUE' must be 31163 able to hold the complete return value. For example, if a 1-, 2- 31164 or 3-byte structure is returned at the most significant end of a 31165 4-byte register, `TARGET_FUNCTION_VALUE' should provide an 31166 `SImode' rtx. 31167 31168 31169File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 31170 3117117.10.9 How Large Values Are Returned 31172------------------------------------- 31173 31174When a function value's mode is `BLKmode' (and in some other cases), 31175the value is not returned according to `TARGET_FUNCTION_VALUE' (*note 31176Scalar Return::). Instead, the caller passes the address of a block of 31177memory in which the value should be stored. This address is called the 31178"structure value address". 31179 31180 This section describes how to control returning structure values in 31181memory. 31182 31183 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 31184 const_tree FNTYPE) 31185 This target hook should return a nonzero value to say to return the 31186 function value in memory, just as large structures are always 31187 returned. Here TYPE will be the data type of the value, and FNTYPE 31188 will be the type of the function doing the returning, or `NULL' for 31189 libcalls. 31190 31191 Note that values of mode `BLKmode' must be explicitly handled by 31192 this function. Also, the option `-fpcc-struct-return' takes 31193 effect regardless of this macro. On most systems, it is possible 31194 to leave the hook undefined; this causes a default definition to 31195 be used, whose value is the constant 1 for `BLKmode' values, and 0 31196 otherwise. 31197 31198 Do not use this hook to indicate that structures and unions should 31199 always be returned in memory. You should instead use 31200 `DEFAULT_PCC_STRUCT_RETURN' to indicate this. 31201 31202 -- Macro: DEFAULT_PCC_STRUCT_RETURN 31203 Define this macro to be 1 if all structure and union return values 31204 must be in memory. Since this results in slower code, this should 31205 be defined only if needed for compatibility with other compilers 31206 or with an ABI. If you define this macro to be 0, then the 31207 conventions used for structure and union return values are decided 31208 by the `TARGET_RETURN_IN_MEMORY' target hook. 31209 31210 If not defined, this defaults to the value 1. 31211 31212 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 31213 This target hook should return the location of the structure value 31214 address (normally a `mem' or `reg'), or 0 if the address is passed 31215 as an "invisible" first argument. Note that FNDECL may be `NULL', 31216 for libcalls. You do not need to define this target hook if the 31217 address is always passed as an "invisible" first argument. 31218 31219 On some architectures the place where the structure value address 31220 is found by the called function is not the same place that the 31221 caller put it. This can be due to register windows, or it could 31222 be because the function prologue moves it to a different place. 31223 INCOMING is `1' or `2' when the location is needed in the context 31224 of the called function, and `0' in the context of the caller. 31225 31226 If INCOMING is nonzero and the address is to be found on the 31227 stack, return a `mem' which refers to the frame pointer. If 31228 INCOMING is `2', the result is being used to fetch the structure 31229 value address at the beginning of a function. If you need to emit 31230 adjusting code, you should do it at this point. 31231 31232 -- Macro: PCC_STATIC_STRUCT_RETURN 31233 Define this macro if the usual system convention on the target 31234 machine for returning structures and unions is for the called 31235 function to return the address of a static variable containing the 31236 value. 31237 31238 Do not define this if the usual system convention is for the 31239 caller to pass an address to the subroutine. 31240 31241 This macro has effect in `-fpcc-struct-return' mode, but it does 31242 nothing when you use `-freg-struct-return' mode. 31243 31244 -- Target Hook: enum machine_mode TARGET_GET_RAW_RESULT_MODE (int 31245 REGNO) 31246 This target hook returns the mode to be used when accessing raw 31247 return registers in `__builtin_return'. Define this macro if the 31248 value in REG_RAW_MODE is not correct. 31249 31250 -- Target Hook: enum machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 31251 This target hook returns the mode to be used when accessing raw 31252 argument registers in `__builtin_apply_args'. Define this macro 31253 if the value in REG_RAW_MODE is not correct. 31254 31255 31256File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 31257 3125817.10.10 Caller-Saves Register Allocation 31259----------------------------------------- 31260 31261If you enable it, GCC can save registers around function calls. This 31262makes it possible to use call-clobbered registers to hold variables that 31263must live across calls. 31264 31265 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS) 31266 A C expression to determine whether it is worthwhile to consider 31267 placing a pseudo-register in a call-clobbered hard register and 31268 saving and restoring it around each function call. The expression 31269 should be 1 when this is worth doing, and 0 otherwise. 31270 31271 If you don't define this macro, a default is used which is good on 31272 most machines: `4 * CALLS < REFS'. 31273 31274 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 31275 A C expression specifying which mode is required for saving NREGS 31276 of a pseudo-register in call-clobbered hard register REGNO. If 31277 REGNO is unsuitable for caller save, `VOIDmode' should be 31278 returned. For most machines this macro need not be defined since 31279 GCC will select the smallest suitable mode. 31280 31281 31282File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 31283 3128417.10.11 Function Entry and Exit 31285-------------------------------- 31286 31287This section describes the macros that output function entry 31288("prologue") and exit ("epilogue") code. 31289 31290 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 31291 HOST_WIDE_INT SIZE) 31292 If defined, a function that outputs the assembler code for entry 31293 to a function. The prologue is responsible for setting up the 31294 stack frame, initializing the frame pointer register, saving 31295 registers that must be saved, and allocating SIZE additional bytes 31296 of storage for the local variables. SIZE is an integer. FILE is 31297 a stdio stream to which the assembler code should be output. 31298 31299 The label for the beginning of the function need not be output by 31300 this macro. That has already been done when the macro is run. 31301 31302 To determine which registers to save, the macro can refer to the 31303 array `regs_ever_live': element R is nonzero if hard register R is 31304 used anywhere within the function. This implies the function 31305 prologue should save register R, provided it is not one of the 31306 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must 31307 likewise use `regs_ever_live'.) 31308 31309 On machines that have "register windows", the function entry code 31310 does not save on the stack the registers that are in the windows, 31311 even if they are supposed to be preserved by function calls; 31312 instead it takes appropriate steps to "push" the register stack, 31313 if any non-call-used registers are used in the function. 31314 31315 On machines where functions may or may not have frame-pointers, the 31316 function entry code must vary accordingly; it must set up the frame 31317 pointer if one is wanted, and not otherwise. To determine whether 31318 a frame pointer is in wanted, the macro can refer to the variable 31319 `frame_pointer_needed'. The variable's value will be 1 at run 31320 time in a function that needs a frame pointer. *Note 31321 Elimination::. 31322 31323 The function entry code is responsible for allocating any stack 31324 space required for the function. This stack space consists of the 31325 regions listed below. In most cases, these regions are allocated 31326 in the order listed, with the last listed region closest to the 31327 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is 31328 defined, and the highest address if it is not defined). You can 31329 use a different order for a machine if doing so is more convenient 31330 or required for compatibility reasons. Except in cases where 31331 required by standard or by a debugger, there is no reason why the 31332 stack layout used by GCC need agree with that used by other 31333 compilers for a machine. 31334 31335 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 31336 If defined, a function that outputs assembler code at the end of a 31337 prologue. This should be used when the function prologue is being 31338 emitted as RTL, and you have some extra assembler that needs to be 31339 emitted. *Note prologue instruction pattern::. 31340 31341 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 31342 If defined, a function that outputs assembler code at the start of 31343 an epilogue. This should be used when the function epilogue is 31344 being emitted as RTL, and you have some extra assembler that needs 31345 to be emitted. *Note epilogue instruction pattern::. 31346 31347 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 31348 HOST_WIDE_INT SIZE) 31349 If defined, a function that outputs the assembler code for exit 31350 from a function. The epilogue is responsible for restoring the 31351 saved registers and stack pointer to their values when the 31352 function was called, and returning control to the caller. This 31353 macro takes the same arguments as the macro 31354 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are 31355 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the 31356 same way. 31357 31358 On some machines, there is a single instruction that does all the 31359 work of returning from the function. On these machines, give that 31360 instruction the name `return' and do not define the macro 31361 `TARGET_ASM_FUNCTION_EPILOGUE' at all. 31362 31363 Do not define a pattern named `return' if you want the 31364 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 31365 switches to control whether return instructions or epilogues are 31366 used, define a `return' pattern with a validity condition that 31367 tests the target switches appropriately. If the `return' 31368 pattern's validity condition is false, epilogues will be used. 31369 31370 On machines where functions may or may not have frame-pointers, the 31371 function exit code must vary accordingly. Sometimes the code for 31372 these two cases is completely different. To determine whether a 31373 frame pointer is wanted, the macro can refer to the variable 31374 `frame_pointer_needed'. The variable's value will be 1 when 31375 compiling a function that needs a frame pointer. 31376 31377 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and 31378 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 31379 The C variable `current_function_is_leaf' is nonzero for such a 31380 function. *Note Leaf Functions::. 31381 31382 On some machines, some functions pop their arguments on exit while 31383 others leave that for the caller to do. For example, the 68020 31384 when given `-mrtd' pops arguments in functions that take a fixed 31385 number of arguments. 31386 31387 Your definition of the macro `RETURN_POPS_ARGS' decides which 31388 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE' 31389 needs to know what was decided. The number of bytes of the current 31390 function's arguments that this function should pop is available in 31391 `crtl->args.pops_args'. *Note Scalar Return::. 31392 31393 * A region of `crtl->args.pretend_args_size' bytes of uninitialized 31394 space just underneath the first argument arriving on the stack. 31395 (This may not be at the very start of the allocated stack region 31396 if the calling sequence has pushed anything else since pushing the 31397 stack arguments. But usually, on such machines, nothing else has 31398 been pushed yet, because the function prologue itself does all the 31399 pushing.) This region is used on machines where an argument may 31400 be passed partly in registers and partly in memory, and, in some 31401 cases to support the features in `<stdarg.h>'. 31402 31403 * An area of memory used to save certain registers used by the 31404 function. The size of this area, which may also include space for 31405 such things as the return address and pointers to previous stack 31406 frames, is machine-specific and usually depends on which registers 31407 have been used in the function. Machines with register windows 31408 often do not require a save area. 31409 31410 * A region of at least SIZE bytes, possibly rounded up to an 31411 allocation boundary, to contain the local variables of the 31412 function. On some machines, this region and the save area may 31413 occur in the opposite order, with the save area closer to the top 31414 of the stack. 31415 31416 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of 31417 `crtl->outgoing_args_size' bytes to be used for outgoing argument 31418 lists of the function. *Note Stack Arguments::. 31419 31420 -- Macro: EXIT_IGNORE_STACK 31421 Define this macro as a C expression that is nonzero if the return 31422 instruction or the function epilogue ignores the value of the stack 31423 pointer; in other words, if it is safe to delete an instruction to 31424 adjust the stack pointer before a return from the function. The 31425 default is 0. 31426 31427 Note that this macro's value is relevant only for functions for 31428 which frame pointers are maintained. It is never safe to delete a 31429 final stack adjustment in a function that has no frame pointer, 31430 and the compiler knows this regardless of `EXIT_IGNORE_STACK'. 31431 31432 -- Macro: EPILOGUE_USES (REGNO) 31433 Define this macro as a C expression that is nonzero for registers 31434 that are used by the epilogue or the `return' pattern. The stack 31435 and frame pointer registers are already assumed to be used as 31436 needed. 31437 31438 -- Macro: EH_USES (REGNO) 31439 Define this macro as a C expression that is nonzero for registers 31440 that are used by the exception handling mechanism, and so should 31441 be considered live on entry to an exception edge. 31442 31443 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 31444 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 31445 VCALL_OFFSET, tree FUNCTION) 31446 A function that outputs the assembler code for a thunk function, 31447 used to implement C++ virtual function calls with multiple 31448 inheritance. The thunk acts as a wrapper around a virtual 31449 function, adjusting the implicit object parameter before handing 31450 control off to the real function. 31451 31452 First, emit code to add the integer DELTA to the location that 31453 contains the incoming first argument. Assume that this argument 31454 contains a pointer, and is the one used to pass the `this' pointer 31455 in C++. This is the incoming argument _before_ the function 31456 prologue, e.g. `%o0' on a sparc. The addition must preserve the 31457 values of all other incoming arguments. 31458 31459 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 31460 be made after adding `delta'. In particular, if P is the adjusted 31461 pointer, the following adjustment should be made: 31462 31463 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 31464 31465 After the additions, emit code to jump to FUNCTION, which is a 31466 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does 31467 not touch the return address. Hence returning from FUNCTION will 31468 return to whoever called the current `thunk'. 31469 31470 The effect must be as if FUNCTION had been called directly with 31471 the adjusted first argument. This macro is responsible for 31472 emitting all of the code for a thunk function; 31473 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 31474 are not invoked. 31475 31476 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 31477 been extracted from it.) It might possibly be useful on some 31478 targets, but probably not. 31479 31480 If you do not define this macro, the target-independent code in 31481 the C++ front end will generate a less efficient heavyweight thunk 31482 that calls FUNCTION instead of jumping to it. The generic 31483 approach does not support varargs. 31484 31485 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 31486 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 31487 VCALL_OFFSET, const_tree FUNCTION) 31488 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would 31489 be able to output the assembler code for the thunk function 31490 specified by the arguments it is passed, and false otherwise. In 31491 the latter case, the generic approach will be used by the C++ 31492 front end, with the limitations previously exposed. 31493 31494 31495File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 31496 3149717.10.12 Generating Code for Profiling 31498-------------------------------------- 31499 31500These macros will help you generate code for profiling. 31501 31502 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 31503 A C statement or compound statement to output to FILE some 31504 assembler code to call the profiling subroutine `mcount'. 31505 31506 The details of how `mcount' expects to be called are determined by 31507 your operating system environment, not by GCC. To figure them out, 31508 compile a small program for profiling using the system's installed 31509 C compiler and look at the assembler code that results. 31510 31511 Older implementations of `mcount' expect the address of a counter 31512 variable to be loaded into some register. The name of this 31513 variable is `LP' followed by the number LABELNO, so you would 31514 generate the name using `LP%d' in a `fprintf'. 31515 31516 -- Macro: PROFILE_HOOK 31517 A C statement or compound statement to output to FILE some assembly 31518 code to call the profiling subroutine `mcount' even the target does 31519 not support profiling. 31520 31521 -- Macro: NO_PROFILE_COUNTERS 31522 Define this macro to be an expression with a nonzero value if the 31523 `mcount' subroutine on your system does not need a counter variable 31524 allocated for each function. This is true for almost all modern 31525 implementations. If you define this macro, you must not use the 31526 LABELNO argument to `FUNCTION_PROFILER'. 31527 31528 -- Macro: PROFILE_BEFORE_PROLOGUE 31529 Define this macro if the code for function profiling should come 31530 before the function prologue. Normally, the profiling code comes 31531 after. 31532 31533 31534File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 31535 3153617.10.13 Permitting tail calls 31537------------------------------ 31538 31539 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 31540 EXP) 31541 True if it is ok to do sibling call optimization for the specified 31542 call expression EXP. DECL will be the called function, or `NULL' 31543 if this is an indirect call. 31544 31545 It is not uncommon for limitations of calling conventions to 31546 prevent tail calls to functions outside the current unit of 31547 translation, or during PIC compilation. The hook is used to 31548 enforce these restrictions, as the `sibcall' md pattern can not 31549 fail, or fall over to a "normal" call. The criteria for 31550 successful sibling call optimization may vary greatly between 31551 different architectures. 31552 31553 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 31554 Add any hard registers to REGS that are live on entry to the 31555 function. This hook only needs to be defined to provide registers 31556 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 31557 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 31558 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, 31559 FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM, 31560 ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM. 31561 31562 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 31563 hard_reg_set_container *) 31564 This hook should add additional registers that are computed by the 31565 prologue to the hard regset for shrink-wrapping optimization 31566 purposes. 31567 31568 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 31569 True if a function's return statements should be checked for 31570 matching the function's return type. This includes checking for 31571 falling off the end of a non-void function. Return false if no 31572 such check should be made. 31573 31574 31575File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 31576 3157717.10.14 Stack smashing protection 31578---------------------------------- 31579 31580 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 31581 This hook returns a `DECL' node for the external variable to use 31582 for the stack protection guard. This variable is initialized by 31583 the runtime to some random value and is used to initialize the 31584 guard value that is placed at the top of the local stack frame. 31585 The type of this variable must be `ptr_type_node'. 31586 31587 The default version of this hook creates a variable called 31588 `__stack_chk_guard', which is normally defined in `libgcc2.c'. 31589 31590 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 31591 This hook returns a `CALL_EXPR' that alerts the runtime that the 31592 stack protect guard variable has been modified. This expression 31593 should involve a call to a `noreturn' function. 31594 31595 The default version of this hook invokes a function called 31596 `__stack_chk_fail', taking no arguments. This function is 31597 normally defined in `libgcc2.c'. 31598 31599 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 31600 struct gcc_options *OPTS) 31601 Whether this target supports splitting the stack when the options 31602 described in OPTS have been passed. This is called after options 31603 have been parsed, so the target may reject splitting the stack in 31604 some configurations. The default version of this hook returns 31605 false. If REPORT is true, this function may issue a warning or 31606 error; if REPORT is false, it must simply return a value 31607 31608 31609File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 31610 3161117.11 Implementing the Varargs Macros 31612===================================== 31613 31614GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that 31615work without change on machines that pass arguments on the stack. 31616Other machines require their own implementations of varargs, and the 31617two machine independent header files must have conditionals to include 31618it. 31619 31620 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the 31621calling convention for `va_start'. The traditional implementation 31622takes just one argument, which is the variable in which to store the 31623argument pointer. The ISO implementation of `va_start' takes an 31624additional second argument. The user is supposed to write the last 31625named argument of the function here. 31626 31627 However, `va_start' should not use this argument. The way to find the 31628end of the named arguments is with the built-in functions described 31629below. 31630 31631 -- Macro: __builtin_saveregs () 31632 Use this built-in function to save the argument registers in 31633 memory so that the varargs mechanism can access them. Both ISO 31634 and traditional versions of `va_start' must use 31635 `__builtin_saveregs', unless you use 31636 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 31637 31638 On some machines, `__builtin_saveregs' is open-coded under the 31639 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On 31640 other machines, it calls a routine written in assembler language, 31641 found in `libgcc2.c'. 31642 31643 Code generated for the call to `__builtin_saveregs' appears at the 31644 beginning of the function, as opposed to where the call to 31645 `__builtin_saveregs' is written, regardless of what the code is. 31646 This is because the registers must be saved before the function 31647 starts to use them for its own purposes. 31648 31649 -- Macro: __builtin_next_arg (LASTARG) 31650 This builtin returns the address of the first anonymous stack 31651 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns 31652 the address of the location above the first anonymous stack 31653 argument. Use it in `va_start' to initialize the pointer for 31654 fetching arguments from the stack. Also use it in `va_start' to 31655 verify that the second parameter LASTARG is the last named argument 31656 of the current function. 31657 31658 -- Macro: __builtin_classify_type (OBJECT) 31659 Since each machine has its own conventions for which data types are 31660 passed in which kind of register, your implementation of `va_arg' 31661 has to embody these conventions. The easiest way to categorize the 31662 specified data type is to use `__builtin_classify_type' together 31663 with `sizeof' and `__alignof__'. 31664 31665 `__builtin_classify_type' ignores the value of OBJECT, considering 31666 only its data type. It returns an integer describing what kind of 31667 type that is--integer, floating, pointer, structure, and so on. 31668 31669 The file `typeclass.h' defines an enumeration that you can use to 31670 interpret the values of `__builtin_classify_type'. 31671 31672 These machine description macros help implement varargs: 31673 31674 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 31675 If defined, this hook produces the machine-specific code for a 31676 call to `__builtin_saveregs'. This code will be moved to the very 31677 beginning of the function, before any parameter access are made. 31678 The return value of this function should be an RTX that contains 31679 the value to use as the return of `__builtin_saveregs'. 31680 31681 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 31682 ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int 31683 *PRETEND_ARGS_SIZE, int SECOND_TIME) 31684 This target hook offers an alternative to using 31685 `__builtin_saveregs' and defining the hook 31686 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 31687 register arguments into the stack so that all the arguments appear 31688 to have been passed consecutively on the stack. Once this is 31689 done, you can use the standard implementation of varargs that 31690 works for machines that pass all their arguments on the stack. 31691 31692 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data 31693 structure, containing the values that are obtained after 31694 processing the named arguments. The arguments MODE and TYPE 31695 describe the last named argument--its machine mode and its data 31696 type as a tree node. 31697 31698 The target hook should do two things: first, push onto the stack 31699 all the argument registers _not_ used for the named arguments, and 31700 second, store the size of the data thus pushed into the 31701 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 31702 that you store here will serve as additional offset for setting up 31703 the stack frame. 31704 31705 Because you must generate code to push the anonymous arguments at 31706 compile time without knowing their data types, 31707 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 31708 have just a single category of argument register and use it 31709 uniformly for all data types. 31710 31711 If the argument SECOND_TIME is nonzero, it means that the 31712 arguments of the function are being analyzed for the second time. 31713 This happens for an inline function, which is not actually 31714 compiled until the end of the source file. The hook 31715 `TARGET_SETUP_INCOMING_VARARGS' should not generate any 31716 instructions in this case. 31717 31718 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 31719 CA) 31720 Define this hook to return `true' if the location where a function 31721 argument is passed depends on whether or not it is a named 31722 argument. 31723 31724 This hook controls how the NAMED argument to `TARGET_FUNCTION_ARG' 31725 is set for varargs and stdarg functions. If this hook returns 31726 `true', the NAMED argument is always true for named arguments, and 31727 false for unnamed arguments. If it returns `false', but 31728 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all 31729 arguments are treated as named. Otherwise, all named arguments 31730 except the last are treated as named. 31731 31732 You need not define this hook if it always returns `false'. 31733 31734 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 31735 (cumulative_args_t CA) 31736 If you need to conditionally change ABIs so that one works with 31737 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 31738 `TARGET_SETUP_INCOMING_VARARGS' nor 31739 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook 31740 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used, 31741 `false' otherwise. Otherwise, you should not define this hook. 31742 31743 31744File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 31745 3174617.12 Trampolines for Nested Functions 31747====================================== 31748 31749A "trampoline" is a small piece of code that is created at run time 31750when the address of a nested function is taken. It normally resides on 31751the stack, in the stack frame of the containing function. These macros 31752tell GCC how to generate code to allocate and initialize a trampoline. 31753 31754 The instructions in the trampoline must do two things: load a constant 31755address into the static chain register, and jump to the real address of 31756the nested function. On CISC machines such as the m68k, this requires 31757two instructions, a move immediate and a jump. Then the two addresses 31758exist in the trampoline as word-long immediate operands. On RISC 31759machines, it is often necessary to load each address into a register in 31760two parts. Then pieces of each address form separate immediate 31761operands. 31762 31763 The code generated to initialize the trampoline must store the variable 31764parts--the static chain value and the function address--into the 31765immediate operands of the instructions. On a CISC machine, this is 31766simply a matter of copying each address to a memory reference at the 31767proper offset from the start of the trampoline. On a RISC machine, it 31768may be necessary to take out pieces of the address and store them 31769separately. 31770 31771 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 31772 This hook is called by `assemble_trampoline_template' to output, 31773 on the stream F, assembler code for a block of data that contains 31774 the constant parts of a trampoline. This code should not include a 31775 label--the label is taken care of automatically. 31776 31777 If you do not define this hook, it means no template is needed for 31778 the target. Do not define this hook on systems where the block 31779 move code to copy the trampoline into place would be larger than 31780 the code to generate it on the spot. 31781 31782 -- Macro: TRAMPOLINE_SECTION 31783 Return the section into which the trampoline template is to be 31784 placed (*note Sections::). The default value is 31785 `readonly_data_section'. 31786 31787 -- Macro: TRAMPOLINE_SIZE 31788 A C expression for the size in bytes of the trampoline, as an 31789 integer. 31790 31791 -- Macro: TRAMPOLINE_ALIGNMENT 31792 Alignment required for trampolines, in bits. 31793 31794 If you don't define this macro, the value of `FUNCTION_ALIGNMENT' 31795 is used for aligning trampolines. 31796 31797 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 31798 rtx STATIC_CHAIN) 31799 This hook is called to initialize a trampoline. M_TRAMP is an RTX 31800 for the memory block for the trampoline; FNDECL is the 31801 `FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX 31802 for the static chain value that should be passed to the function 31803 when it is called. 31804 31805 If the target defines `TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 31806 first thing this hook should do is emit a block move into M_TRAMP 31807 from the memory block returned by `assemble_trampoline_template'. 31808 Note that the block move need only cover the constant parts of the 31809 trampoline. If the target isolates the variable parts of the 31810 trampoline to the end, not all `TRAMPOLINE_SIZE' bytes need be 31811 copied. 31812 31813 If the target requires any other actions, such as flushing caches 31814 or enabling stack execution, these actions should be performed 31815 after initializing the trampoline proper. 31816 31817 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 31818 This hook should perform any machine-specific adjustment in the 31819 address of the trampoline. Its argument contains the address of 31820 the memory block that was passed to `TARGET_TRAMPOLINE_INIT'. In 31821 case the address to be used for a function call should be 31822 different from the address at which the template was stored, the 31823 different address should be returned; otherwise ADDR should be 31824 returned unchanged. If this hook is not defined, ADDR will be 31825 used for function calls. 31826 31827 Implementing trampolines is difficult on many machines because they 31828have separate instruction and data caches. Writing into a stack 31829location fails to clear the memory in the instruction cache, so when 31830the program jumps to that location, it executes the old contents. 31831 31832 Here are two possible solutions. One is to clear the relevant parts of 31833the instruction cache whenever a trampoline is set up. The other is to 31834make all trampolines identical, by having them jump to a standard 31835subroutine. The former technique makes trampoline execution faster; the 31836latter makes initialization faster. 31837 31838 To clear the instruction cache when a trampoline is initialized, define 31839the following macro. 31840 31841 -- Macro: CLEAR_INSN_CACHE (BEG, END) 31842 If defined, expands to a C expression clearing the _instruction 31843 cache_ in the specified interval. The definition of this macro 31844 would typically be a series of `asm' statements. Both BEG and END 31845 are both pointer expressions. 31846 31847 To use a standard subroutine, define the following macro. In addition, 31848you must make sure that the instructions in a trampoline fill an entire 31849cache line with identical instructions, or else ensure that the 31850beginning of the trampoline code is always aligned at the same point in 31851its cache line. Look in `m68k.h' as a guide. 31852 31853 -- Macro: TRANSFER_FROM_TRAMPOLINE 31854 Define this macro if trampolines need a special subroutine to do 31855 their work. The macro should expand to a series of `asm' 31856 statements which will be compiled with GCC. They go in a library 31857 function named `__transfer_from_trampoline'. 31858 31859 If you need to avoid executing the ordinary prologue code of a 31860 compiled C function when you jump to the subroutine, you can do so 31861 by placing a special label of your own in the assembler code. Use 31862 one `asm' statement to generate an assembler label, and another to 31863 make the label global. Then trampolines can use that label to 31864 jump directly to your special assembler code. 31865 31866 31867File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 31868 3186917.13 Implicit Calls to Library Routines 31870======================================== 31871 31872Here is an explanation of implicit calls to library routines. 31873 31874 -- Macro: DECLARE_LIBRARY_RENAMES 31875 This macro, if defined, should expand to a piece of C code that 31876 will get expanded when compiling functions for libgcc.a. It can 31877 be used to provide alternate names for GCC's internal library 31878 functions if there are ABI-mandated names that the compiler should 31879 provide. 31880 31881 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 31882 This hook should declare additional library routines or rename 31883 existing ones, using the functions `set_optab_libfunc' and 31884 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls 31885 this macro after initializing all the normal library routines. 31886 31887 The default is to do nothing. Most ports don't need to define 31888 this hook. 31889 31890 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 31891 If false (the default), internal library routines start with two 31892 underscores. If set to true, these routines start with `__gnu_' 31893 instead. E.g., `__muldi3' changes to `__gnu_muldi3'. This 31894 currently only affects functions defined in `libgcc2.c'. If this 31895 is set to true, the `tm.h' file must also `#define 31896 LIBGCC2_GNU_PREFIX'. 31897 31898 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 31899 This macro should return `true' if the library routine that 31900 implements the floating point comparison operator COMPARISON in 31901 mode MODE will return a boolean, and FALSE if it will return a 31902 tristate. 31903 31904 GCC's own floating point libraries return tristates from the 31905 comparison operators, so the default returns false always. Most 31906 ports don't need to define this macro. 31907 31908 -- Macro: TARGET_LIB_INT_CMP_BIASED 31909 This macro should evaluate to `true' if the integer comparison 31910 functions (like `__cmpdi2') return 0 to indicate that the first 31911 operand is smaller than the second, 1 to indicate that they are 31912 equal, and 2 to indicate that the first operand is greater than 31913 the second. If this macro evaluates to `false' the comparison 31914 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 31915 target uses the routines in `libgcc.a', you do not need to define 31916 this macro. 31917 31918 -- Macro: TARGET_EDOM 31919 The value of `EDOM' on the target machine, as a C integer constant 31920 expression. If you don't define this macro, GCC does not attempt 31921 to deposit the value of `EDOM' into `errno' directly. Look in 31922 `/usr/include/errno.h' to find the value of `EDOM' on your system. 31923 31924 If you do not define `TARGET_EDOM', then compiled code reports 31925 domain errors by calling the library function and letting it 31926 report the error. If mathematical functions on your system use 31927 `matherr' when there is an error, then you should leave 31928 `TARGET_EDOM' undefined so that `matherr' is used normally. 31929 31930 -- Macro: GEN_ERRNO_RTX 31931 Define this macro as a C expression to create an rtl expression 31932 that refers to the global "variable" `errno'. (On certain systems, 31933 `errno' may not actually be a variable.) If you don't define this 31934 macro, a reasonable default is used. 31935 31936 -- Macro: TARGET_C99_FUNCTIONS 31937 When this macro is nonzero, GCC will implicitly optimize `sin' 31938 calls into `sinf' and similarly for other functions defined by C99 31939 standard. The default is zero because a number of existing 31940 systems lack support for these functions in their runtime so this 31941 macro needs to be redefined to one on systems that do support the 31942 C99 runtime. 31943 31944 -- Macro: TARGET_HAS_SINCOS 31945 When this macro is nonzero, GCC will implicitly optimize calls to 31946 `sin' and `cos' with the same argument to a call to `sincos'. The 31947 default is zero. The target has to provide the following 31948 functions: 31949 void sincos(double x, double *sin, double *cos); 31950 void sincosf(float x, float *sin, float *cos); 31951 void sincosl(long double x, long double *sin, long double *cos); 31952 31953 -- Macro: NEXT_OBJC_RUNTIME 31954 Set this macro to 1 to use the "NeXT" Objective-C message sending 31955 conventions by default. This calling convention involves passing 31956 the object, the selector and the method arguments all at once to 31957 the method-lookup library function. This is the usual setting 31958 when targeting Darwin/Mac OS X systems, which have the NeXT 31959 runtime installed. 31960 31961 If the macro is set to 0, the "GNU" Objective-C message sending 31962 convention will be used by default. This convention passes just 31963 the object and the selector to the method-lookup function, which 31964 returns a pointer to the method. 31965 31966 In either case, it remains possible to select code-generation for 31967 the alternate scheme, by means of compiler command line switches. 31968 31969 31970File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 31971 3197217.14 Addressing Modes 31973====================== 31974 31975This is about addressing modes. 31976 31977 -- Macro: HAVE_PRE_INCREMENT 31978 -- Macro: HAVE_PRE_DECREMENT 31979 -- Macro: HAVE_POST_INCREMENT 31980 -- Macro: HAVE_POST_DECREMENT 31981 A C expression that is nonzero if the machine supports 31982 pre-increment, pre-decrement, post-increment, or post-decrement 31983 addressing respectively. 31984 31985 -- Macro: HAVE_PRE_MODIFY_DISP 31986 -- Macro: HAVE_POST_MODIFY_DISP 31987 A C expression that is nonzero if the machine supports pre- or 31988 post-address side-effect generation involving constants other than 31989 the size of the memory operand. 31990 31991 -- Macro: HAVE_PRE_MODIFY_REG 31992 -- Macro: HAVE_POST_MODIFY_REG 31993 A C expression that is nonzero if the machine supports pre- or 31994 post-address side-effect generation involving a register 31995 displacement. 31996 31997 -- Macro: CONSTANT_ADDRESS_P (X) 31998 A C expression that is 1 if the RTX X is a constant which is a 31999 valid address. On most machines the default definition of 32000 `(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 32001 but a few machines are more restrictive as to which constant 32002 addresses are supported. 32003 32004 -- Macro: CONSTANT_P (X) 32005 `CONSTANT_P', which is defined by target-independent code, accepts 32006 integer-values expressions whose values are not explicitly known, 32007 such as `symbol_ref', `label_ref', and `high' expressions and 32008 `const' arithmetic expressions, in addition to `const_int' and 32009 `const_double' expressions. 32010 32011 -- Macro: MAX_REGS_PER_ADDRESS 32012 A number, the maximum number of registers that can appear in a 32013 valid memory address. Note that it is up to you to specify a 32014 value equal to the maximum number that 32015 `TARGET_LEGITIMATE_ADDRESS_P' would ever accept. 32016 32017 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (enum machine_mode 32018 MODE, rtx X, bool STRICT) 32019 A function that returns whether X (an RTX) is a legitimate memory 32020 address on the target machine for a memory operand of mode MODE. 32021 32022 Legitimate addresses are defined in two variants: a strict variant 32023 and a non-strict one. The STRICT parameter chooses which variant 32024 is desired by the caller. 32025 32026 The strict variant is used in the reload pass. It must be defined 32027 so that any pseudo-register that has not been allocated a hard 32028 register is considered a memory reference. This is because in 32029 contexts where some kind of register is required, a 32030 pseudo-register with no hard register must be rejected. For 32031 non-hard registers, the strict variant should look up the 32032 `reg_renumber' array; it should then proceed using the hard 32033 register number in the array, or treat the pseudo as a memory 32034 reference if the array holds `-1'. 32035 32036 The non-strict variant is used in other passes. It must be 32037 defined to accept all pseudo-registers in every context where some 32038 kind of register is required. 32039 32040 Normally, constant addresses which are the sum of a `symbol_ref' 32041 and an integer are stored inside a `const' RTX to mark them as 32042 constant. Therefore, there is no need to recognize such sums 32043 specifically as legitimate addresses. Normally you would simply 32044 recognize any `const' as legitimate. 32045 32046 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 32047 sums that are not marked with `const'. It assumes that a naked 32048 `plus' indicates indexing. If so, then you _must_ reject such 32049 naked constant sums as illegitimate addresses, so that none of 32050 them will be given to `PRINT_OPERAND_ADDRESS'. 32051 32052 On some machines, whether a symbolic address is legitimate depends 32053 on the section that the address refers to. On these machines, 32054 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the 32055 information into the `symbol_ref', and then check for it here. 32056 When you see a `const', you will have to look inside it to find the 32057 `symbol_ref' in order to determine the section. *Note Assembler 32058 Format::. 32059 32060 Some ports are still using a deprecated legacy substitute for this 32061 hook, the `GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 32062 syntax: 32063 32064 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 32065 32066 and should `goto LABEL' if the address X is a valid address on the 32067 target machine for a memory operand of mode MODE. 32068 32069 Compiler source files that want to use the strict variant of this 32070 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef 32071 REG_OK_STRICT' conditional to define the strict variant in that 32072 case and the non-strict variant otherwise. 32073 32074 Using the hook is usually simpler because it limits the number of 32075 files that are recompiled when changes are made. 32076 32077 -- Macro: TARGET_MEM_CONSTRAINT 32078 A single character to be used instead of the default `'m'' 32079 character for general memory addresses. This defines the 32080 constraint letter which matches the memory addresses accepted by 32081 `TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 32082 support new address formats in your back end without changing the 32083 semantics of the `'m'' constraint. This is necessary in order to 32084 preserve functionality of inline assembly constructs using the 32085 `'m'' constraint. 32086 32087 -- Macro: FIND_BASE_TERM (X) 32088 A C expression to determine the base term of address X, or to 32089 provide a simplified version of X from which `alias.c' can easily 32090 find the base term. This macro is used in only two places: 32091 `find_base_value' and `find_base_term' in `alias.c'. 32092 32093 It is always safe for this macro to not be defined. It exists so 32094 that alias analysis can understand machine-dependent addresses. 32095 32096 The typical use of this macro is to handle addresses containing a 32097 label_ref or symbol_ref within an UNSPEC. 32098 32099 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, enum 32100 machine_mode MODE) 32101 This hook is given an invalid memory address X for an operand of 32102 mode MODE and should try to return a valid memory address. 32103 32104 X will always be the result of a call to `break_out_memory_refs', 32105 and OLDX will be the operand that was given to that function to 32106 produce X. 32107 32108 The code of the hook should not alter the substructure of X. If 32109 it transforms X into a more legitimate form, it should return the 32110 new X. 32111 32112 It is not necessary for this hook to come up with a legitimate 32113 address, with the exception of native TLS addresses (*note 32114 Emulated TLS::). The compiler has standard ways of doing so in 32115 all cases. In fact, if the target supports only emulated TLS, it 32116 is safe to omit this hook or make it return X if it cannot find a 32117 valid way to legitimize the address. But often a machine-dependent 32118 strategy can generate better code. 32119 32120 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 32121 WIN) 32122 A C compound statement that attempts to replace X, which is an 32123 address that needs reloading, with a valid memory address for an 32124 operand of mode MODE. WIN will be a C statement label elsewhere 32125 in the code. It is not necessary to define this macro, but it 32126 might be useful for performance reasons. 32127 32128 For example, on the i386, it is sometimes possible to use a single 32129 reload register instead of two by reloading a sum of two pseudo 32130 registers into a register. On the other hand, for number of RISC 32131 processors offsets are limited so that often an intermediate 32132 address needs to be generated in order to address a stack slot. 32133 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 32134 intermediate addresses generated for adjacent some stack slots can 32135 be made identical, and thus be shared. 32136 32137 _Note_: This macro should be used with caution. It is necessary 32138 to know something of how reload works in order to effectively use 32139 this, and it is quite easy to produce macros that build in too 32140 much knowledge of reload internals. 32141 32142 _Note_: This macro must be able to reload an address created by a 32143 previous invocation of this macro. If it fails to handle such 32144 addresses then the compiler may generate incorrect code or abort. 32145 32146 The macro definition should use `push_reload' to indicate parts 32147 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 32148 suitable to be passed unaltered to `push_reload'. 32149 32150 The code generated by this macro must not alter the substructure of 32151 X. If it transforms X into a more legitimate form, it should 32152 assign X (which will always be a C variable) a new value. This 32153 also applies to parts that you change indirectly by calling 32154 `push_reload'. 32155 32156 The macro definition may use `strict_memory_address_p' to test if 32157 the address has become legitimate. 32158 32159 If you want to change only a part of X, one standard way of doing 32160 this is to use `copy_rtx'. Note, however, that it unshares only a 32161 single level of rtl. Thus, if the part to be changed is not at the 32162 top level, you'll need to replace first the top level. It is not 32163 necessary for this macro to come up with a legitimate address; 32164 but often a machine-dependent strategy can generate better code. 32165 32166 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 32167 addr_space_t ADDRSPACE) 32168 This hook returns `true' if memory address ADDR in address space 32169 ADDRSPACE can have different meanings depending on the machine 32170 mode of the memory reference it is used for or if the address is 32171 valid for some modes but not others. 32172 32173 Autoincrement and autodecrement addresses typically have 32174 mode-dependent effects because the amount of the increment or 32175 decrement is the size of the operand being addressed. Some 32176 machines have other mode-dependent addresses. Many RISC machines 32177 have no mode-dependent addresses. 32178 32179 You may assume that ADDR is a valid address for the machine. 32180 32181 The default version of this hook returns `false'. 32182 32183 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (enum machine_mode 32184 MODE, rtx X) 32185 This hook returns true if X is a legitimate constant for a 32186 MODE-mode immediate operand on the target machine. You can assume 32187 that X satisfies `CONSTANT_P', so you need not check this. 32188 32189 The default definition returns true. 32190 32191 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 32192 This hook is used to undo the possibly obfuscating effects of the 32193 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target 32194 macros. Some backend implementations of these macros wrap symbol 32195 references inside an `UNSPEC' rtx to represent PIC or similar 32196 addressing modes. This target hook allows GCC's optimizers to 32197 understand the semantics of these opaque `UNSPEC's by converting 32198 them back into their original form. 32199 32200 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 32201 This hook should return true if X should not be emitted into debug 32202 sections. 32203 32204 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (enum machine_mode 32205 MODE, rtx X) 32206 This hook should return true if X is of a form that cannot (or 32207 should not) be spilled to the constant pool. MODE is the mode of 32208 X. 32209 32210 The default version of this hook returns false. 32211 32212 The primary reason to define this hook is to prevent reload from 32213 deciding that a non-legitimate constant would be better reloaded 32214 from the constant pool instead of spilling and reloading a register 32215 holding the constant. This restriction is often true of addresses 32216 of TLS symbols for various targets. 32217 32218 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum 32219 machine_mode MODE, const_rtx X) 32220 This hook should return true if pool entries for constant X can be 32221 placed in an `object_block' structure. MODE is the mode of X. 32222 32223 The default version returns false for all constants. 32224 32225 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 32226 This hook should return true if pool entries for DECL should be 32227 placed in an `object_block' structure. 32228 32229 The default version returns true for all decls. 32230 32231 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool 32232 MD_FN, bool SQRT) 32233 This hook should return the DECL of a function that implements 32234 reciprocal of the builtin function with builtin function code FN, 32235 or `NULL_TREE' if such a function is not available. MD_FN is true 32236 when FN is a code of a machine-dependent builtin function. When 32237 SQRT is true, additional optimizations that apply only to the 32238 reciprocal of a square root function are performed, and only 32239 reciprocals of `sqrt' function are valid. 32240 32241 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 32242 This hook should return the DECL of a function F that given an 32243 address ADDR as an argument returns a mask M that can be used to 32244 extract from two vectors the relevant data that resides in ADDR in 32245 case ADDR is not properly aligned. 32246 32247 The autovectorizer, when vectorizing a load operation from an 32248 address ADDR that may be unaligned, will generate two vector loads 32249 from the two aligned addresses around ADDR. It then generates a 32250 `REALIGN_LOAD' operation to extract the relevant data from the two 32251 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and 32252 V2, are the two vectors, each of size VS, and the third argument, 32253 OFF, defines how the data will be extracted from these two 32254 vectors: if OFF is 0, then the returned vector is V2; otherwise, 32255 the returned vector is composed from the last VS-OFF elements of 32256 V1 concatenated to the first OFF elements of V2. 32257 32258 If this hook is defined, the autovectorizer will generate a call 32259 to F (using the DECL tree that this hook returns) and will use the 32260 return value of F as the argument OFF to `REALIGN_LOAD'. 32261 Therefore, the mask M returned by F should comply with the 32262 semantics expected by `REALIGN_LOAD' described above. If this 32263 hook is not defined, then ADDR will be used as the argument OFF to 32264 `REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 32265 will be considered. 32266 32267 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 32268 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 32269 Returns cost of different scalar or vector statements for 32270 vectorization cost model. For vector memory operations the cost 32271 may depend on type (VECTYPE) and misalignment value (MISALIGN). 32272 32273 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 32274 (const_tree TYPE, bool IS_PACKED) 32275 Return true if vector alignment is reachable (by peeling N 32276 iterations) for the given type. 32277 32278 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST_OK (enum 32279 MACHINE_MODE, const unsigned char *SEL) 32280 Return true if a vector created for `vec_perm_const' is valid. 32281 32282 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 32283 CODE, tree DEST_TYPE, tree SRC_TYPE) 32284 This hook should return the DECL of a function that implements 32285 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 32286 The value of CODE is one of the enumerators in `enum tree_code' and 32287 specifies how the conversion is to be applied (truncation, 32288 rounding, etc.). 32289 32290 If this hook is defined, the autovectorizer will use the 32291 `TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 32292 conversion. Otherwise, it will return `NULL_TREE'. 32293 32294 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 32295 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 32296 This hook should return the decl of a function that implements the 32297 vectorized variant of the builtin function with builtin function 32298 code CODE or `NULL_TREE' if such a function is not available. The 32299 value of FNDECL is the builtin function declaration. The return 32300 type of the vectorized function shall be of vector type 32301 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 32302 32303 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 32304 (enum machine_mode MODE, const_tree TYPE, int MISALIGNMENT, 32305 bool IS_PACKED) 32306 This hook should return true if the target supports misaligned 32307 vector store/load of a specific factor denoted in the MISALIGNMENT 32308 parameter. The vector store/load should be of machine mode MODE 32309 and the elements in the vectors should be of type TYPE. IS_PACKED 32310 parameter is true if the memory access is defined in a packed 32311 struct. 32312 32313 -- Target Hook: enum machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 32314 (enum machine_mode MODE) 32315 This hook should return the preferred mode for vectorizing scalar 32316 mode MODE. The default is equal to `word_mode', because the 32317 vectorizer can do some transformations even in absence of 32318 specialized SIMD hardware. 32319 32320 -- Target Hook: unsigned int 32321TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void) 32322 This hook should return a mask of sizes that should be iterated 32323 over after trying to autovectorize using the vector size derived 32324 from the mode returned by `TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 32325 The default is zero which means to not iterate over other vector 32326 sizes. 32327 32328 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 32329 *LOOP_INFO) 32330 This hook should initialize target-specific data structures in 32331 preparation for modeling the costs of vectorizing a loop or basic 32332 block. The default allocates three unsigned integers for 32333 accumulating costs for the prologue, body, and epilogue of the 32334 loop or basic block. If LOOP_INFO is non-NULL, it identifies the 32335 loop being vectorized; otherwise a single block is being 32336 vectorized. 32337 32338 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 32339 int COUNT, enum vect_cost_for_stmt KIND, struct 32340 _stmt_vec_info *STMT_INFO, int MISALIGN, enum 32341 vect_cost_model_location WHERE) 32342 This hook should update the target-specific DATA in response to 32343 adding COUNT copies of the given KIND of statement to a loop or 32344 basic block. The default adds the builtin vectorizer cost for the 32345 copies of the statement to the accumulator specified by WHERE, 32346 (the prologue, body, or epilogue) and returns the amount added. 32347 The return value should be viewed as a tentative cost that may 32348 later be revised. 32349 32350 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, 32351 unsigned *PROLOGUE_COST, unsigned *BODY_COST, unsigned 32352 *EPILOGUE_COST) 32353 This hook should complete calculations of the cost of vectorizing 32354 a loop or basic block based on DATA, and return the prologue, 32355 body, and epilogue costs as unsigned integers. The default 32356 returns the value of the three accumulators. 32357 32358 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 32359 This hook should release DATA and any related data structures 32360 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 32361 accumulator. 32362 32363 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_LOAD (tree) 32364 This hook should return the built-in decl needed to load a vector 32365 of the given type within a transaction. 32366 32367 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_STORE (tree) 32368 This hook should return the built-in decl needed to store a vector 32369 of the given type within a transaction. 32370 32371 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 32372 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 32373 Target builtin that implements vector gather operation. 32374 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is 32375 scalar type of the index, scaled by SCALE. The default is 32376 `NULL_TREE' which means to not vectorize gather loads. 32377 32378 32379File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 32380 3238117.15 Anchored Addresses 32382======================== 32383 32384GCC usually addresses every static object as a separate entity. For 32385example, if we have: 32386 32387 static int a, b, c; 32388 int foo (void) { return a + b + c; } 32389 32390 the code for `foo' will usually calculate three separate symbolic 32391addresses: those of `a', `b' and `c'. On some targets, it would be 32392better to calculate just one symbolic address and access the three 32393variables relative to it. The equivalent pseudocode would be something 32394like: 32395 32396 int foo (void) 32397 { 32398 register int *xr = &x; 32399 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 32400 } 32401 32402 (which isn't valid C). We refer to shared addresses like `x' as 32403"section anchors". Their use is controlled by `-fsection-anchors'. 32404 32405 The hooks below describe the target properties that GCC needs to know 32406in order to make effective use of section anchors. It won't use 32407section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or 32408`TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 32409 32410 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 32411 The minimum offset that should be applied to a section anchor. On 32412 most targets, it should be the smallest offset that can be applied 32413 to a base register while still giving a legitimate address for 32414 every mode. The default value is 0. 32415 32416 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 32417 Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) 32418 offset that should be applied to section anchors. The default 32419 value is 0. 32420 32421 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 32422 Write the assembly code to define section anchor X, which is a 32423 `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The 32424 hook is called with the assembly output position set to the 32425 beginning of `SYMBOL_REF_BLOCK (X)'. 32426 32427 If `ASM_OUTPUT_DEF' is available, the hook's default definition 32428 uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'. 32429 If `ASM_OUTPUT_DEF' is not available, the hook's default definition 32430 is `NULL', which disables the use of section anchors altogether. 32431 32432 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 32433 Return true if GCC should attempt to use anchors to access 32434 `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 32435 and `!SYMBOL_REF_ANCHOR_P (X)'. 32436 32437 The default version is correct for most targets, but you might 32438 need to intercept this hook to handle things like target-specific 32439 attributes or target-specific sections. 32440 32441 32442File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 32443 3244417.16 Condition Code Status 32445=========================== 32446 32447The macros in this section can be split in two families, according to 32448the two ways of representing condition codes in GCC. 32449 32450 The first representation is the so called `(cc0)' representation 32451(*note Jump Patterns::), where all instructions can have an implicit 32452clobber of the condition codes. The second is the condition code 32453register representation, which provides better schedulability for 32454architectures that do have a condition code register, but on which most 32455instructions do not affect it. The latter category includes most RISC 32456machines. 32457 32458 The implicit clobbering poses a strong restriction on the placement of 32459the definition and use of the condition code, which need to be in 32460adjacent insns for machines using `(cc0)'. This can prevent important 32461optimizations on some machines. For example, on the IBM RS/6000, there 32462is a delay for taken branches unless the condition code register is set 32463three instructions earlier than the conditional branch. The instruction 32464scheduler cannot perform this optimization if it is not permitted to 32465separate the definition and use of the condition code register. 32466 32467 For this reason, it is possible and suggested to use a register to 32468represent the condition code for new ports. If there is a specific 32469condition code register in the machine, use a hard register. If the 32470condition code or comparison result can be placed in any general 32471register, or if there are multiple condition registers, use a pseudo 32472register. Registers used to store the condition code value will 32473usually have a mode that is in class `MODE_CC'. 32474 32475 Alternatively, you can use `BImode' if the comparison operator is 32476specified already in the compare instruction. In this case, you are not 32477interested in most macros in this section. 32478 32479* Menu: 32480 32481* CC0 Condition Codes:: Old style representation of condition codes. 32482* MODE_CC Condition Codes:: Modern representation of condition codes. 32483 32484 32485File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 32486 3248717.16.1 Representation of condition codes using `(cc0)' 32488------------------------------------------------------- 32489 32490The file `conditions.h' defines a variable `cc_status' to describe how 32491the condition code was computed (in case the interpretation of the 32492condition code depends on the instruction that it was set by). This 32493variable contains the RTL expressions on which the condition code is 32494currently based, and several standard flags. 32495 32496 Sometimes additional machine-specific flags must be defined in the 32497machine description header file. It can also add additional 32498machine-specific information by defining `CC_STATUS_MDEP'. 32499 32500 -- Macro: CC_STATUS_MDEP 32501 C code for a data type which is used for declaring the `mdep' 32502 component of `cc_status'. It defaults to `int'. 32503 32504 This macro is not used on machines that do not use `cc0'. 32505 32506 -- Macro: CC_STATUS_MDEP_INIT 32507 A C expression to initialize the `mdep' field to "empty". The 32508 default definition does nothing, since most machines don't use the 32509 field anyway. If you want to use the field, you should probably 32510 define this macro to initialize it. 32511 32512 This macro is not used on machines that do not use `cc0'. 32513 32514 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 32515 A C compound statement to set the components of `cc_status' 32516 appropriately for an insn INSN whose body is EXP. It is this 32517 macro's responsibility to recognize insns that set the condition 32518 code as a byproduct of other activity as well as those that 32519 explicitly set `(cc0)'. 32520 32521 This macro is not used on machines that do not use `cc0'. 32522 32523 If there are insns that do not set the condition code but do alter 32524 other machine registers, this macro must check to see whether they 32525 invalidate the expressions that the condition code is recorded as 32526 reflecting. For example, on the 68000, insns that store in address 32527 registers do not set the condition code, which means that usually 32528 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 32529 But suppose that the previous insn set the condition code based on 32530 location `a4@(102)' and the current insn stores a new value in 32531 `a4'. Although the condition code is not changed by this, it will 32532 no longer be true that it reflects the contents of `a4@(102)'. 32533 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 32534 to say that nothing is known about the condition code value. 32535 32536 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 32537 the results of peephole optimization: insns whose patterns are 32538 `parallel' RTXs containing various `reg', `mem' or constants which 32539 are just the operands. The RTL structure of these insns is not 32540 sufficient to indicate what the insns actually do. What 32541 `NOTICE_UPDATE_CC' should do when it sees one is just to run 32542 `CC_STATUS_INIT'. 32543 32544 A possible definition of `NOTICE_UPDATE_CC' is to call a function 32545 that looks at an attribute (*note Insn Attributes::) named, for 32546 example, `cc'. This avoids having detailed information about 32547 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 32548 32549 32550File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 32551 3255217.16.2 Representation of condition codes using registers 32553--------------------------------------------------------- 32554 32555 -- Macro: SELECT_CC_MODE (OP, X, Y) 32556 On many machines, the condition code may be produced by other 32557 instructions than compares, for example the branch can use 32558 directly the condition code set by a subtract instruction. 32559 However, on some machines when the condition code is set this way 32560 some bits (such as the overflow bit) are not set in the same way 32561 as a test instruction, so that a different branch instruction must 32562 be used for some conditional branches. When this happens, use the 32563 machine mode of the condition code register to record different 32564 formats of the condition code register. Modes can also be used to 32565 record which compare instruction (e.g. a signed or an unsigned 32566 comparison) produced the condition codes. 32567 32568 If other modes than `CCmode' are required, add them to 32569 `MACHINE-modes.def' and define `SELECT_CC_MODE' to choose a mode 32570 given an operand of a compare. This is needed because the modes 32571 have to be chosen not only during RTL generation but also, for 32572 example, by instruction combination. The result of 32573 `SELECT_CC_MODE' should be consistent with the mode used in the 32574 patterns; for example to support the case of the add on the SPARC 32575 discussed above, we have the pattern 32576 32577 (define_insn "" 32578 [(set (reg:CC_NOOV 0) 32579 (compare:CC_NOOV 32580 (plus:SI (match_operand:SI 0 "register_operand" "%r") 32581 (match_operand:SI 1 "arith_operand" "rI")) 32582 (const_int 0)))] 32583 "" 32584 "...") 32585 32586 together with a `SELECT_CC_MODE' that returns `CC_NOOVmode' for 32587 comparisons whose argument is a `plus': 32588 32589 #define SELECT_CC_MODE(OP,X,Y) \ 32590 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 32591 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 32592 ? CCFPEmode : CCFPmode) \ 32593 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 32594 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 32595 ? CC_NOOVmode : CCmode)) 32596 32597 Another reason to use modes is to retain information on which 32598 operands were used by the comparison; see `REVERSIBLE_CC_MODE' 32599 later in this section. 32600 32601 You should define this macro if and only if you define extra CC 32602 modes in `MACHINE-modes.def'. 32603 32604 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 32605 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) (CODE, OP0, OP1, 32606 OP0_PRESERVE_VALUE) 32607 On some machines not all possible comparisons are defined, but you 32608 can convert an invalid comparison into a valid one. For example, 32609 the Alpha does not have a `GT' comparison, but you can use an `LT' 32610 comparison instead and swap the order of the operands. 32611 32612 On such machines, implement this hook to do any required 32613 conversions. CODE is the initial comparison code and OP0 and OP1 32614 are the left and right operands of the comparison, respectively. 32615 If OP0_PRESERVE_VALUE is `true' the implementation is not allowed 32616 to change the value of OP0 since the value might be used in RTXs 32617 which aren't comparisons. E.g. the implementation is not allowed 32618 to swap operands in that case. 32619 32620 GCC will not assume that the comparison resulting from this macro 32621 is valid but will see if the resulting insn matches a pattern in 32622 the `md' file. 32623 32624 You need not to implement this hook if it would never change the 32625 comparison code or operands. 32626 32627 -- Macro: REVERSIBLE_CC_MODE (MODE) 32628 A C expression whose value is one if it is always safe to reverse a 32629 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 32630 return MODE for a floating-point inequality comparison, then 32631 `REVERSIBLE_CC_MODE (MODE)' must be zero. 32632 32633 You need not define this macro if it would always returns zero or 32634 if the floating-point format is anything other than 32635 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 32636 the SPARC, where floating-point inequality comparisons are given 32637 either `CCFPEmode' or `CCFPmode': 32638 32639 #define REVERSIBLE_CC_MODE(MODE) \ 32640 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 32641 32642 -- Macro: REVERSE_CONDITION (CODE, MODE) 32643 A C expression whose value is reversed condition code of the CODE 32644 for comparison done in CC_MODE MODE. The macro is used only in 32645 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 32646 case machine has some non-standard way how to reverse certain 32647 conditionals. For instance in case all floating point conditions 32648 are non-trapping, compiler may freely convert unordered compares 32649 to ordered ones. Then definition may look like: 32650 32651 #define REVERSE_CONDITION(CODE, MODE) \ 32652 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 32653 : reverse_condition_maybe_unordered (CODE)) 32654 32655 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 32656 *P1, unsigned int *P2) 32657 On targets which do not use `(cc0)', and which use a hard register 32658 rather than a pseudo-register to hold condition codes, the regular 32659 CSE passes are often not able to identify cases in which the hard 32660 register is set to a common value. Use this hook to enable a 32661 small pass which optimizes such cases. This hook should return 32662 true to enable this pass, and it should set the integers to which 32663 its arguments point to the hard register numbers used for 32664 condition codes. When there is only one such register, as is true 32665 on most systems, the integer pointed to by P2 should be set to 32666 `INVALID_REGNUM'. 32667 32668 The default version of this hook returns false. 32669 32670 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum 32671 machine_mode M1, enum machine_mode M2) 32672 On targets which use multiple condition code modes in class 32673 `MODE_CC', it is sometimes the case that a comparison can be 32674 validly done in more than one mode. On such a system, define this 32675 target hook to take two mode arguments and to return a mode in 32676 which both comparisons may be validly done. If there is no such 32677 mode, return `VOIDmode'. 32678 32679 The default version of this hook checks whether the modes are the 32680 same. If they are, it returns that mode. If they are different, 32681 it returns `VOIDmode'. 32682 32683 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 32684 If the target has a dedicated flags register, and it needs to use 32685 the post-reload comparison elimination pass, then this value 32686 should be set appropriately. 32687 32688 32689File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 32690 3269117.17 Describing Relative Costs of Operations 32692============================================= 32693 32694These macros let you describe the relative speed of various operations 32695on the target machine. 32696 32697 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 32698 A C expression for the cost of moving data of mode MODE from a 32699 register in class FROM to one in class TO. The classes are 32700 expressed using the enumeration values such as `GENERAL_REGS'. A 32701 value of 2 is the default; other values are interpreted relative to 32702 that. 32703 32704 It is not required that the cost always equal 2 when FROM is the 32705 same as TO; on some machines it is expensive to move between 32706 registers if they are not general registers. 32707 32708 If reload sees an insn consisting of a single `set' between two 32709 hard registers, and if `REGISTER_MOVE_COST' applied to their 32710 classes returns a value of 2, reload does not check to ensure that 32711 the constraints of the insn are met. Setting a cost of other than 32712 2 will allow reload to verify that the constraints are met. You 32713 should do this if the `movM' pattern's constraints do not allow 32714 such copying. 32715 32716 These macros are obsolete, new ports should use the target hook 32717 `TARGET_REGISTER_MOVE_COST' instead. 32718 32719 -- Target Hook: int TARGET_REGISTER_MOVE_COST (enum machine_mode MODE, 32720 reg_class_t FROM, reg_class_t TO) 32721 This target hook should return the cost of moving data of mode MODE 32722 from a register in class FROM to one in class TO. The classes are 32723 expressed using the enumeration values such as `GENERAL_REGS'. A 32724 value of 2 is the default; other values are interpreted relative to 32725 that. 32726 32727 It is not required that the cost always equal 2 when FROM is the 32728 same as TO; on some machines it is expensive to move between 32729 registers if they are not general registers. 32730 32731 If reload sees an insn consisting of a single `set' between two 32732 hard registers, and if `TARGET_REGISTER_MOVE_COST' applied to their 32733 classes returns a value of 2, reload does not check to ensure that 32734 the constraints of the insn are met. Setting a cost of other than 32735 2 will allow reload to verify that the constraints are met. You 32736 should do this if the `movM' pattern's constraints do not allow 32737 such copying. 32738 32739 The default version of this function returns 2. 32740 32741 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 32742 A C expression for the cost of moving data of mode MODE between a 32743 register of class CLASS and memory; IN is zero if the value is to 32744 be written to memory, nonzero if it is to be read in. This cost 32745 is relative to those in `REGISTER_MOVE_COST'. If moving between 32746 registers and memory is more expensive than between two registers, 32747 you should define this macro to express the relative cost. 32748 32749 If you do not define this macro, GCC uses a default cost of 4 plus 32750 the cost of copying via a secondary reload register, if one is 32751 needed. If your machine requires a secondary reload register to 32752 copy between memory and a register of CLASS but the reload 32753 mechanism is more complex than copying via an intermediate, define 32754 this macro to reflect the actual cost of the move. 32755 32756 GCC defines the function `memory_move_secondary_cost' if secondary 32757 reloads are needed. It computes the costs due to copying via a 32758 secondary register. If your machine copies from memory using a 32759 secondary register in the conventional way but the default base 32760 value of 4 is not correct for your machine, define this macro to 32761 add some other value to the result of that function. The 32762 arguments to that function are the same as to this macro. 32763 32764 These macros are obsolete, new ports should use the target hook 32765 `TARGET_MEMORY_MOVE_COST' instead. 32766 32767 -- Target Hook: int TARGET_MEMORY_MOVE_COST (enum machine_mode MODE, 32768 reg_class_t RCLASS, bool IN) 32769 This target hook should return the cost of moving data of mode MODE 32770 between a register of class RCLASS and memory; IN is `false' if 32771 the value is to be written to memory, `true' if it is to be read 32772 in. This cost is relative to those in `TARGET_REGISTER_MOVE_COST'. 32773 If moving between registers and memory is more expensive than 32774 between two registers, you should add this target hook to express 32775 the relative cost. 32776 32777 If you do not add this target hook, GCC uses a default cost of 4 32778 plus the cost of copying via a secondary reload register, if one is 32779 needed. If your machine requires a secondary reload register to 32780 copy between memory and a register of RCLASS but the reload 32781 mechanism is more complex than copying via an intermediate, use 32782 this target hook to reflect the actual cost of the move. 32783 32784 GCC defines the function `memory_move_secondary_cost' if secondary 32785 reloads are needed. It computes the costs due to copying via a 32786 secondary register. If your machine copies from memory using a 32787 secondary register in the conventional way but the default base 32788 value of 4 is not correct for your machine, use this target hook 32789 to add some other value to the result of that function. The 32790 arguments to that function are the same as to this target hook. 32791 32792 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 32793 A C expression for the cost of a branch instruction. A value of 1 32794 is the default; other values are interpreted relative to that. 32795 Parameter SPEED_P is true when the branch in question should be 32796 optimized for speed. When it is false, `BRANCH_COST' should 32797 return a value optimal for code size rather than performance. 32798 PREDICTABLE_P is true for well-predicted branches. On many 32799 architectures the `BRANCH_COST' can be reduced then. 32800 32801 Here are additional macros which do not specify precise relative costs, 32802but only that certain actions are more expensive than GCC would 32803ordinarily expect. 32804 32805 -- Macro: SLOW_BYTE_ACCESS 32806 Define this macro as a C expression which is nonzero if accessing 32807 less than a word of memory (i.e. a `char' or a `short') is no 32808 faster than accessing a word of memory, i.e., if such access 32809 require more than one instruction or if there is no difference in 32810 cost between byte and (aligned) word loads. 32811 32812 When this macro is not defined, the compiler will access a field by 32813 finding the smallest containing object; when it is defined, a 32814 fullword load will be used if alignment permits. Unless bytes 32815 accesses are faster than word accesses, using word accesses is 32816 preferable since it may eliminate subsequent memory access if 32817 subsequent accesses occur to other fields in the same word of the 32818 structure, but to different bytes. 32819 32820 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 32821 Define this macro to be the value 1 if memory accesses described 32822 by the MODE and ALIGNMENT parameters have a cost many times greater 32823 than aligned accesses, for example if they are emulated in a trap 32824 handler. 32825 32826 When this macro is nonzero, the compiler will act as if 32827 `STRICT_ALIGNMENT' were nonzero when generating code for block 32828 moves. This can cause significantly more instructions to be 32829 produced. Therefore, do not set this macro nonzero if unaligned 32830 accesses only add a cycle or two to the time for a memory access. 32831 32832 If the value of this macro is always zero, it need not be defined. 32833 If this macro is defined, it should produce a nonzero value when 32834 `STRICT_ALIGNMENT' is nonzero. 32835 32836 -- Macro: MOVE_RATIO (SPEED) 32837 The threshold of number of scalar memory-to-memory move insns, 32838 _below_ which a sequence of insns should be generated instead of a 32839 string move insn or a library call. Increasing the value will 32840 always make code faster, but eventually incurs high cost in 32841 increased code size. 32842 32843 Note that on machines where the corresponding move insn is a 32844 `define_expand' that emits a sequence of insns, this macro counts 32845 the number of such sequences. 32846 32847 The parameter SPEED is true if the code is currently being 32848 optimized for speed rather than size. 32849 32850 If you don't define this, a reasonable default is used. 32851 32852 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT) 32853 A C expression used to determine whether `move_by_pieces' will be 32854 used to copy a chunk of memory, or whether some other block move 32855 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 32856 returns less than `MOVE_RATIO'. 32857 32858 -- Macro: MOVE_MAX_PIECES 32859 A C expression used by `move_by_pieces' to determine the largest 32860 unit a load or store used to copy memory is. Defaults to 32861 `MOVE_MAX'. 32862 32863 -- Macro: CLEAR_RATIO (SPEED) 32864 The threshold of number of scalar move insns, _below_ which a 32865 sequence of insns should be generated to clear memory instead of a 32866 string clear insn or a library call. Increasing the value will 32867 always make code faster, but eventually incurs high cost in 32868 increased code size. 32869 32870 The parameter SPEED is true if the code is currently being 32871 optimized for speed rather than size. 32872 32873 If you don't define this, a reasonable default is used. 32874 32875 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT) 32876 A C expression used to determine whether `clear_by_pieces' will be 32877 used to clear a chunk of memory, or whether some other block clear 32878 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 32879 returns less than `CLEAR_RATIO'. 32880 32881 -- Macro: SET_RATIO (SPEED) 32882 The threshold of number of scalar move insns, _below_ which a 32883 sequence of insns should be generated to set memory to a constant 32884 value, instead of a block set insn or a library call. Increasing 32885 the value will always make code faster, but eventually incurs high 32886 cost in increased code size. 32887 32888 The parameter SPEED is true if the code is currently being 32889 optimized for speed rather than size. 32890 32891 If you don't define this, it defaults to the value of `MOVE_RATIO'. 32892 32893 -- Macro: SET_BY_PIECES_P (SIZE, ALIGNMENT) 32894 A C expression used to determine whether `store_by_pieces' will be 32895 used to set a chunk of memory to a constant value, or whether some 32896 other mechanism will be used. Used by `__builtin_memset' when 32897 storing values other than constant zero. Defaults to 1 if 32898 `move_by_pieces_ninsns' returns less than `SET_RATIO'. 32899 32900 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT) 32901 A C expression used to determine whether `store_by_pieces' will be 32902 used to set a chunk of memory to a constant string value, or 32903 whether some other mechanism will be used. Used by 32904 `__builtin_strcpy' when called with a constant source string. 32905 Defaults to 1 if `move_by_pieces_ninsns' returns less than 32906 `MOVE_RATIO'. 32907 32908 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 32909 A C expression used to determine whether a load postincrement is a 32910 good thing to use for a given mode. Defaults to the value of 32911 `HAVE_POST_INCREMENT'. 32912 32913 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 32914 A C expression used to determine whether a load postdecrement is a 32915 good thing to use for a given mode. Defaults to the value of 32916 `HAVE_POST_DECREMENT'. 32917 32918 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 32919 A C expression used to determine whether a load preincrement is a 32920 good thing to use for a given mode. Defaults to the value of 32921 `HAVE_PRE_INCREMENT'. 32922 32923 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 32924 A C expression used to determine whether a load predecrement is a 32925 good thing to use for a given mode. Defaults to the value of 32926 `HAVE_PRE_DECREMENT'. 32927 32928 -- Macro: USE_STORE_POST_INCREMENT (MODE) 32929 A C expression used to determine whether a store postincrement is 32930 a good thing to use for a given mode. Defaults to the value of 32931 `HAVE_POST_INCREMENT'. 32932 32933 -- Macro: USE_STORE_POST_DECREMENT (MODE) 32934 A C expression used to determine whether a store postdecrement is 32935 a good thing to use for a given mode. Defaults to the value of 32936 `HAVE_POST_DECREMENT'. 32937 32938 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 32939 This macro is used to determine whether a store preincrement is a 32940 good thing to use for a given mode. Defaults to the value of 32941 `HAVE_PRE_INCREMENT'. 32942 32943 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 32944 This macro is used to determine whether a store predecrement is a 32945 good thing to use for a given mode. Defaults to the value of 32946 `HAVE_PRE_DECREMENT'. 32947 32948 -- Macro: NO_FUNCTION_CSE 32949 Define this macro if it is as good or better to call a constant 32950 function address than to call an address kept in a register. 32951 32952 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 32953 Define this macro if a non-short-circuit operation produced by 32954 `fold_range_test ()' is optimal. This macro defaults to true if 32955 `BRANCH_COST' is greater than or equal to the value 2. 32956 32957 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int 32958 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 32959 This target hook describes the relative costs of RTL expressions. 32960 32961 The cost may depend on the precise form of the expression, which is 32962 available for examination in X, and the fact that X appears as 32963 operand OPNO of an expression with rtx code OUTER_CODE. That is, 32964 the hook can assume that there is some rtx Y such that `GET_CODE 32965 (Y) == OUTER_CODE' and such that either (a) `XEXP (Y, OPNO) == X' 32966 or (b) `XVEC (Y, OPNO)' contains X. 32967 32968 CODE is X's expression code--redundant, since it can be obtained 32969 with `GET_CODE (X)'. 32970 32971 In implementing this hook, you can use the construct 32972 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions. 32973 32974 On entry to the hook, `*TOTAL' contains a default estimate for the 32975 cost of the expression. The hook should modify this value as 32976 necessary. Traditionally, the default costs are `COSTS_N_INSNS 32977 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and 32978 modulus operations, and `COSTS_N_INSNS (1)' for all other 32979 operations. 32980 32981 When optimizing for code size, i.e. when `speed' is false, this 32982 target hook should be used to estimate the relative size cost of 32983 an expression, again relative to `COSTS_N_INSNS'. 32984 32985 The hook returns true when all subexpressions of X have been 32986 processed, and false when `rtx_cost' should recurse. 32987 32988 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, enum 32989 machine_mode MODE, addr_space_t AS, bool SPEED) 32990 This hook computes the cost of an addressing mode that contains 32991 ADDRESS. If not defined, the cost is computed from the ADDRESS 32992 expression and the `TARGET_RTX_COST' hook. 32993 32994 For most CISC machines, the default cost is a good approximation 32995 of the true cost of the addressing mode. However, on RISC 32996 machines, all instructions normally have the same length and 32997 execution time. Hence all addresses will have equal costs. 32998 32999 In cases where more than one form of an address is known, the form 33000 with the lowest cost will be used. If multiple forms have the 33001 same, lowest, cost, the one that is the most complex will be used. 33002 33003 For example, suppose an address that is equal to the sum of a 33004 register and a constant is used twice in the same basic block. 33005 When this macro is not defined, the address will be computed in a 33006 register and memory references will be indirect through that 33007 register. On machines where the cost of the addressing mode 33008 containing the sum is no higher than that of a simple indirect 33009 reference, this will produce an additional instruction and 33010 possibly require an additional register. Proper specification of 33011 this macro eliminates this overhead for such machines. 33012 33013 This hook is never called with an invalid address. 33014 33015 On machines where an address involving more than one register is as 33016 cheap as an address computation involving only one register, 33017 defining `TARGET_ADDRESS_COST' to reflect this can cause two 33018 registers to be live over a region of code where only one would 33019 have been if `TARGET_ADDRESS_COST' were not defined in that 33020 manner. This effect should be considered in the definition of 33021 this macro. Equivalent costs should probably only be given to 33022 addresses with different numbers of registers on machines with 33023 lots of registers. 33024 33025 33026File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 33027 3302817.18 Adjusting the Instruction Scheduler 33029========================================= 33030 33031The instruction scheduler may need a fair amount of machine-specific 33032adjustment in order to produce good code. GCC provides several target 33033hooks for this purpose. It is usually enough to define just a few of 33034them: try the first ones in this list first. 33035 33036 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 33037 This hook returns the maximum number of instructions that can ever 33038 issue at the same time on the target machine. The default is one. 33039 Although the insn scheduler can define itself the possibility of 33040 issue an insn on the same cycle, the value can serve as an 33041 additional constraint to issue insns on the same simulated 33042 processor cycle (see hooks `TARGET_SCHED_REORDER' and 33043 `TARGET_SCHED_REORDER2'). This value must be constant over the 33044 entire compilation. If you need it to vary depending on what the 33045 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'. 33046 33047 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 33048 VERBOSE, rtx INSN, int MORE) 33049 This hook is executed by the scheduler after it has scheduled an 33050 insn from the ready list. It should return the number of insns 33051 which can still be issued in the current cycle. The default is 33052 `MORE - 1' for insns other than `CLOBBER' and `USE', which 33053 normally are not counted against the issue rate. You should 33054 define this hook if some insns take more machine resources than 33055 others, so that fewer insns can follow them in the same cycle. 33056 FILE is either a null pointer, or a stdio stream to write any 33057 debug output to. VERBOSE is the verbose level provided by 33058 `-fsched-verbose-N'. INSN is the instruction that was scheduled. 33059 33060 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx 33061 DEP_INSN, int COST) 33062 This function corrects the value of COST based on the relationship 33063 between INSN and DEP_INSN through the dependence LINK. It should 33064 return the new value. The default is to make no adjustment to 33065 COST. This can be used for example to specify to the scheduler 33066 using the traditional pipeline description that an output- or 33067 anti-dependence does not incur the same cost as a data-dependence. 33068 If the scheduler using the automaton based pipeline description, 33069 the cost of anti-dependence is zero and the cost of 33070 output-dependence is maximum of one and the difference of latency 33071 times of the first and the second insns. If these values are not 33072 acceptable, you could use the hook to modify them too. See also 33073 *note Processor pipeline description::. 33074 33075 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int 33076 PRIORITY) 33077 This hook adjusts the integer scheduling priority PRIORITY of 33078 INSN. It should return the new priority. Increase the priority to 33079 execute INSN earlier, reduce the priority to execute INSN later. 33080 Do not define this hook if you do not need to adjust the 33081 scheduling priorities of insns. 33082 33083 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx 33084 *READY, int *N_READYP, int CLOCK) 33085 This hook is executed by the scheduler after it has scheduled the 33086 ready list, to allow the machine description to reorder it (for 33087 example to combine two small instructions together on `VLIW' 33088 machines). FILE is either a null pointer, or a stdio stream to 33089 write any debug output to. VERBOSE is the verbose level provided 33090 by `-fsched-verbose-N'. READY is a pointer to the ready list of 33091 instructions that are ready to be scheduled. N_READYP is a 33092 pointer to the number of elements in the ready list. The scheduler 33093 reads the ready list in reverse order, starting with 33094 READY[*N_READYP - 1] and going to READY[0]. CLOCK is the timer 33095 tick of the scheduler. You may modify the ready list and the 33096 number of ready insns. The return value is the number of insns 33097 that can issue this cycle; normally this is just `issue_rate'. 33098 See also `TARGET_SCHED_REORDER2'. 33099 33100 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 33101 rtx *READY, int *N_READYP, int CLOCK) 33102 Like `TARGET_SCHED_REORDER', but called at a different time. That 33103 function is called whenever the scheduler starts a new cycle. 33104 This one is called once per iteration over a cycle, immediately 33105 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list 33106 and return the number of insns to be scheduled in the same cycle. 33107 Defining this hook can be useful if there are frequent situations 33108 where scheduling one insn causes other insns to become ready in 33109 the same cycle. These other insns can then be taken into account 33110 properly. 33111 33112 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx 33113 HEAD, rtx TAIL) 33114 This hook is called after evaluation forward dependencies of insns 33115 in chain given by two parameter values (HEAD and TAIL 33116 correspondingly) but before insns scheduling of the insn chain. 33117 For example, it can be used for better insn classification if it 33118 requires analysis of dependencies. This hook can use backward and 33119 forward dependencies of the insn scheduler because they are already 33120 calculated. 33121 33122 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 33123 MAX_READY) 33124 This hook is executed by the scheduler at the beginning of each 33125 block of instructions that are to be scheduled. FILE is either a 33126 null pointer, or a stdio stream to write any debug output to. 33127 VERBOSE is the verbose level provided by `-fsched-verbose-N'. 33128 MAX_READY is the maximum number of insns in the current scheduling 33129 region that can be live at the same time. This can be used to 33130 allocate scratch space if it is needed, e.g. by 33131 `TARGET_SCHED_REORDER'. 33132 33133 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 33134 This hook is executed by the scheduler at the end of each block of 33135 instructions that are to be scheduled. It can be used to perform 33136 cleanup of any actions done by the other scheduling hooks. FILE 33137 is either a null pointer, or a stdio stream to write any debug 33138 output to. VERBOSE is the verbose level provided by 33139 `-fsched-verbose-N'. 33140 33141 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int 33142 VERBOSE, int OLD_MAX_UID) 33143 This hook is executed by the scheduler after function level 33144 initializations. FILE is either a null pointer, or a stdio stream 33145 to write any debug output to. VERBOSE is the verbose level 33146 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 33147 uid when scheduling begins. 33148 33149 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 33150 VERBOSE) 33151 This is the cleanup hook corresponding to 33152 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 33153 stdio stream to write any debug output to. VERBOSE is the verbose 33154 level provided by `-fsched-verbose-N'. 33155 33156 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 33157 The hook returns an RTL insn. The automaton state used in the 33158 pipeline hazard recognizer is changed as if the insn were scheduled 33159 when the new simulated processor cycle starts. Usage of the hook 33160 may simplify the automaton pipeline description for some VLIW 33161 processors. If the hook is defined, it is used only for the 33162 automaton based pipeline description. The default is not to 33163 change the state when the new simulated processor cycle starts. 33164 33165 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 33166 The hook can be used to initialize data used by the previous hook. 33167 33168 -- Target Hook: rtx TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 33169 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 33170 to changed the state as if the insn were scheduled when the new 33171 simulated processor cycle finishes. 33172 33173 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 33174 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 33175 used to initialize data used by the previous hook. 33176 33177 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 33178 The hook to notify target that the current simulated cycle is 33179 about to finish. The hook is analogous to 33180 `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 33181 more complicated situations - e.g., when advancing state on a 33182 single insn is not enough. 33183 33184 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 33185 The hook to notify target that new simulated cycle has just 33186 started. The hook is analogous to 33187 `TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 33188 more complicated situations - e.g., when advancing state on a 33189 single insn is not enough. 33190 33191 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 33192 (void) 33193 This hook controls better choosing an insn from the ready insn 33194 queue for the DFA-based insn scheduler. Usually the scheduler 33195 chooses the first insn from the queue. If the hook returns a 33196 positive value, an additional scheduler code tries all 33197 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 33198 ()' subsequent ready insns to choose an insn whose issue will 33199 result in maximal number of issued insns on the same cycle. For 33200 the VLIW processor, the code could actually solve the problem of 33201 packing simple insns into the VLIW insn. Of course, if the rules 33202 of VLIW packing are described in the automaton. 33203 33204 This code also could be used for superscalar RISC processors. Let 33205 us consider a superscalar RISC processor with 3 pipelines. Some 33206 insns can be executed in pipelines A or B, some insns can be 33207 executed only in pipelines B or C, and one insn can be executed in 33208 pipeline B. The processor may issue the 1st insn into A and the 33209 2nd one into B. In this case, the 3rd insn will wait for freeing B 33210 until the next cycle. If the scheduler issues the 3rd insn the 33211 first, the processor could issue all 3 insns per cycle. 33212 33213 Actually this code demonstrates advantages of the automaton based 33214 pipeline hazard recognizer. We try quickly and easy many insn 33215 schedules to choose the best one. 33216 33217 The default is no multipass scheduling. 33218 33219 -- Target Hook: int 33220TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx INSN) 33221 This hook controls what insns from the ready insn queue will be 33222 considered for the multipass insn scheduling. If the hook returns 33223 zero for INSN, the insn will be not chosen to be issued. 33224 33225 The default is that any ready insns can be chosen to be issued. 33226 33227 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 33228 *DATA, char *READY_TRY, int N_READY, bool FIRST_CYCLE_INSN_P) 33229 This hook prepares the target backend for a new round of multipass 33230 scheduling. 33231 33232 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 33233 *DATA, char *READY_TRY, int N_READY, rtx INSN, const void 33234 *PREV_DATA) 33235 This hook is called when multipass scheduling evaluates 33236 instruction INSN. 33237 33238 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 33239 (const void *DATA, char *READY_TRY, int N_READY) 33240 This is called when multipass scheduling backtracks from 33241 evaluation of an instruction. 33242 33243 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const 33244 void *DATA) 33245 This hook notifies the target about the result of the concluded 33246 current round of multipass scheduling. 33247 33248 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 33249 *DATA) 33250 This hook initializes target-specific data used in multipass 33251 scheduling. 33252 33253 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 33254 *DATA) 33255 This hook finalizes target-specific data used in multipass 33256 scheduling. 33257 33258 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 33259 VERBOSE, rtx INSN, int LAST_CLOCK, int CLOCK, int *SORT_P) 33260 This hook is called by the insn scheduler before issuing INSN on 33261 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 33262 this processor cycle. Instead, the processor cycle is advanced. 33263 If *SORT_P is zero, the insn ready queue is not sorted on the new 33264 cycle start as usually. DUMP and VERBOSE specify the file and 33265 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 33266 are, respectively, the processor cycle on which the previous insn 33267 has been issued, and the current processor cycle. 33268 33269 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 33270 *_DEP, int COST, int DISTANCE) 33271 This hook is used to define which dependences are considered 33272 costly by the target, so costly that it is not advisable to 33273 schedule the insns that are involved in the dependence too close 33274 to one another. The parameters to this hook are as follows: The 33275 first parameter _DEP is the dependence being evaluated. The 33276 second parameter COST is the cost of the dependence as estimated 33277 by the scheduler, and the third parameter DISTANCE is the distance 33278 in cycles between the two insns. The hook returns `true' if 33279 considering the distance between the two insns the dependence 33280 between them is considered costly by the target, and `false' 33281 otherwise. 33282 33283 Defining this hook can be useful in multiple-issue out-of-order 33284 machines, where (a) it's practically hopeless to predict the 33285 actual data/resource delays, however: (b) there's a better chance 33286 to predict the actual grouping that will be formed, and (c) 33287 correctly emulating the grouping can be very important. In such 33288 targets one may want to allow issuing dependent insns closer to 33289 one another--i.e., closer than the dependence distance; however, 33290 not in cases of "costly dependences", which this hooks allows to 33291 define. 33292 33293 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 33294 This hook is called by the insn scheduler after emitting a new 33295 instruction to the instruction stream. The hook notifies a target 33296 backend to extend its per instruction data structures. 33297 33298 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 33299 Return a pointer to a store large enough to hold target scheduling 33300 context. 33301 33302 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 33303 CLEAN_P) 33304 Initialize store pointed to by TC to hold target scheduling 33305 context. It CLEAN_P is true then initialize TC as if scheduler is 33306 at the beginning of the block. Otherwise, copy the current 33307 context into TC. 33308 33309 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 33310 Copy target scheduling context pointed to by TC to the current 33311 context. 33312 33313 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 33314 Deallocate internal data in target scheduling context pointed to 33315 by TC. 33316 33317 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 33318 Deallocate a store for target scheduling context pointed to by TC. 33319 33320 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, int 33321 REQUEST, rtx *NEW_PAT) 33322 This hook is called by the insn scheduler when INSN has only 33323 speculative dependencies and therefore can be scheduled 33324 speculatively. The hook is used to check if the pattern of INSN 33325 has a speculative version and, in case of successful check, to 33326 generate that speculative pattern. The hook should return 1, if 33327 the instruction has a speculative form, or -1, if it doesn't. 33328 REQUEST describes the type of requested speculation. If the 33329 return value equals 1 then NEW_PAT is assigned the generated 33330 speculative pattern. 33331 33332 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (int DEP_STATUS) 33333 This hook is called by the insn scheduler during generation of 33334 recovery code for INSN. It should return `true', if the 33335 corresponding check instruction should branch to recovery code, or 33336 `false' otherwise. 33337 33338 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx INSN, rtx LABEL, 33339 int MUTATE_P) 33340 This hook is called by the insn scheduler to generate a pattern 33341 for recovery check instruction. If MUTATE_P is zero, then INSN is 33342 a speculative instruction for which the check should be generated. 33343 LABEL is either a label of a basic block, where recovery code 33344 should be emitted, or a null pointer, when requested check doesn't 33345 branch to recovery code (a simple check). If MUTATE_P is nonzero, 33346 then a pattern for a branchy check corresponding to a simple check 33347 denoted by INSN should be generated. In this case LABEL can't be 33348 null. 33349 33350 -- Target Hook: bool 33351TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (const_rtx 33352 INSN) 33353 This hook is used as a workaround for 33354 `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being 33355 called on the first instruction of the ready list. The hook is 33356 used to discard speculative instructions that stand first in the 33357 ready list from being scheduled on the current cycle. If the hook 33358 returns `false', INSN will not be chosen to be issued. For 33359 non-speculative instructions, the hook should always return 33360 `true'. For example, in the ia64 backend the hook is used to 33361 cancel data speculative insns when the ALAT table is nearly full. 33362 33363 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct 33364 spec_info_def *SPEC_INFO) 33365 This hook is used by the insn scheduler to find out what features 33366 should be enabled/used. The structure *SPEC_INFO should be filled 33367 in by the target. The structure describes speculation types that 33368 can be used in the scheduler. 33369 33370 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 33371 This hook is called by the swing modulo scheduler to calculate a 33372 resource-based lower bound which is based on the resources 33373 available in the machine and the resources required by each 33374 instruction. The target backend can use G to calculate such 33375 bound. A very simple lower bound will be used in case this hook 33376 is not implemented: the total number of instructions divided by 33377 the issue rate. 33378 33379 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx INSN, int X) 33380 This hook is called by Haifa Scheduler. It returns true if 33381 dispatch scheduling is supported in hardware and the condition 33382 specified in the parameter is true. 33383 33384 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx INSN, int X) 33385 This hook is called by Haifa Scheduler. It performs the operation 33386 specified in its second parameter. 33387 33388 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 33389 True if the processor has an exposed pipeline, which means that 33390 not just the order of instructions is important for correctness 33391 when scheduling, but also the latencies of operations. 33392 33393 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int 33394 OPC, enum machine_mode MODE) 33395 This hook is called by tree reassociator to determine a level of 33396 parallelism required in output calculations chain. 33397 33398 33399File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 33400 3340117.19 Dividing the Output into Sections (Texts, Data, ...) 33402========================================================== 33403 33404An object file is divided into sections containing different types of 33405data. In the most common case, there are three sections: the "text 33406section", which holds instructions and read-only data; the "data 33407section", which holds initialized writable data; and the "bss section", 33408which holds uninitialized data. Some systems have other kinds of 33409sections. 33410 33411 `varasm.c' provides several well-known sections, such as 33412`text_section', `data_section' and `bss_section'. The normal way of 33413controlling a `FOO_section' variable is to define the associated 33414`FOO_SECTION_ASM_OP' macro, as described below. The macros are only 33415read once, when `varasm.c' initializes itself, so their values must be 33416run-time constants. They may however depend on command-line flags. 33417 33418 _Note:_ Some run-time files, such `crtstuff.c', also make use of the 33419`FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 33420 33421 Some assemblers require a different string to be written every time a 33422section is selected. If your assembler falls into this category, you 33423should define the `TARGET_ASM_INIT_SECTIONS' hook and use 33424`get_unnamed_section' to set up the sections. 33425 33426 You must always create a `text_section', either by defining 33427`TEXT_SECTION_ASM_OP' or by initializing `text_section' in 33428`TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and 33429`DATA_SECTION_ASM_OP'. If you do not create a distinct 33430`readonly_data_section', the default is to reuse `text_section'. 33431 33432 All the other `varasm.c' sections are optional, and are null if the 33433target does not provide them. 33434 33435 -- Macro: TEXT_SECTION_ASM_OP 33436 A C expression whose value is a string, including spacing, 33437 containing the assembler operation that should precede 33438 instructions and read-only data. Normally `"\t.text"' is right. 33439 33440 -- Macro: HOT_TEXT_SECTION_NAME 33441 If defined, a C string constant for the name of the section 33442 containing most frequently executed functions of the program. If 33443 not defined, GCC will provide a default definition if the target 33444 supports named sections. 33445 33446 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 33447 If defined, a C string constant for the name of the section 33448 containing unlikely executed functions in the program. 33449 33450 -- Macro: DATA_SECTION_ASM_OP 33451 A C expression whose value is a string, including spacing, 33452 containing the assembler operation to identify the following data 33453 as writable initialized data. Normally `"\t.data"' is right. 33454 33455 -- Macro: SDATA_SECTION_ASM_OP 33456 If defined, a C expression whose value is a string, including 33457 spacing, containing the assembler operation to identify the 33458 following data as initialized, writable small data. 33459 33460 -- Macro: READONLY_DATA_SECTION_ASM_OP 33461 A C expression whose value is a string, including spacing, 33462 containing the assembler operation to identify the following data 33463 as read-only initialized data. 33464 33465 -- Macro: BSS_SECTION_ASM_OP 33466 If defined, a C expression whose value is a string, including 33467 spacing, containing the assembler operation to identify the 33468 following data as uninitialized global data. If not defined, and 33469 `ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 33470 will be output in the data section if `-fno-common' is passed, 33471 otherwise `ASM_OUTPUT_COMMON' will be used. 33472 33473 -- Macro: SBSS_SECTION_ASM_OP 33474 If defined, a C expression whose value is a string, including 33475 spacing, containing the assembler operation to identify the 33476 following data as uninitialized, writable small data. 33477 33478 -- Macro: TLS_COMMON_ASM_OP 33479 If defined, a C expression whose value is a string containing the 33480 assembler operation to identify the following data as thread-local 33481 common data. The default is `".tls_common"'. 33482 33483 -- Macro: TLS_SECTION_ASM_FLAG 33484 If defined, a C expression whose value is a character constant 33485 containing the flag used to mark a section as a TLS section. The 33486 default is `'T''. 33487 33488 -- Macro: INIT_SECTION_ASM_OP 33489 If defined, a C expression whose value is a string, including 33490 spacing, containing the assembler operation to identify the 33491 following data as initialization code. If not defined, GCC will 33492 assume such a section does not exist. This section has no 33493 corresponding `init_section' variable; it is used entirely in 33494 runtime code. 33495 33496 -- Macro: FINI_SECTION_ASM_OP 33497 If defined, a C expression whose value is a string, including 33498 spacing, containing the assembler operation to identify the 33499 following data as finalization code. If not defined, GCC will 33500 assume such a section does not exist. This section has no 33501 corresponding `fini_section' variable; it is used entirely in 33502 runtime code. 33503 33504 -- Macro: INIT_ARRAY_SECTION_ASM_OP 33505 If defined, a C expression whose value is a string, including 33506 spacing, containing the assembler operation to identify the 33507 following data as part of the `.init_array' (or equivalent) 33508 section. If not defined, GCC will assume such a section does not 33509 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'. 33510 33511 -- Macro: FINI_ARRAY_SECTION_ASM_OP 33512 If defined, a C expression whose value is a string, including 33513 spacing, containing the assembler operation to identify the 33514 following data as part of the `.fini_array' (or equivalent) 33515 section. If not defined, GCC will assume such a section does not 33516 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'. 33517 33518 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 33519 If defined, an ASM statement that switches to a different section 33520 via SECTION_OP, calls FUNCTION, and switches back to the text 33521 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or 33522 `FINI_SECTION_ASM_OP' to calls to initialization and finalization 33523 functions from the init and fini sections. By default, this macro 33524 uses a simple function call. Some ports need hand-crafted 33525 assembly code to avoid dependencies on registers initialized in 33526 the function prologue or to ensure that constant pools don't end 33527 up too far way in the text section. 33528 33529 -- Macro: TARGET_LIBGCC_SDATA_SECTION 33530 If defined, a string which names the section into which small 33531 variables defined in crtstuff and libgcc should go. This is useful 33532 when the target has options for optimizing access to small data, 33533 and you want the crtstuff and libgcc routines to be conservative 33534 in what they expect of your application yet liberal in what your 33535 application expects. For example, for targets with a `.sdata' 33536 section (like MIPS), you could compile crtstuff with `-G 0' so 33537 that it doesn't require small data support from your application, 33538 but use this macro to put small data into `.sdata' so that your 33539 application can access these variables whether it uses small data 33540 or not. 33541 33542 -- Macro: FORCE_CODE_SECTION_ALIGN 33543 If defined, an ASM statement that aligns a code section to some 33544 arbitrary boundary. This is used to force all fragments of the 33545 `.init' and `.fini' sections to have to same alignment and thus 33546 prevent the linker from having to add any padding. 33547 33548 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 33549 Define this macro to be an expression with a nonzero value if jump 33550 tables (for `tablejump' insns) should be output in the text 33551 section, along with the assembler instructions. Otherwise, the 33552 readonly data section is used. 33553 33554 This macro is irrelevant if there is no separate readonly data 33555 section. 33556 33557 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 33558 Define this hook if you need to do something special to set up the 33559 `varasm.c' sections, or if your target has some special sections 33560 of its own that you need to create. 33561 33562 GCC calls this hook after processing the command line, but before 33563 writing any assembly code, and before calling any of the 33564 section-returning hooks described below. 33565 33566 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 33567 Return a mask describing how relocations should be treated when 33568 selecting sections. Bit 1 should be set if global relocations 33569 should be placed in a read-write section; bit 0 should be set if 33570 local relocations should be placed in a read-write section. 33571 33572 The default version of this function returns 3 when `-fpic' is in 33573 effect, and 0 otherwise. The hook is typically redefined when the 33574 target cannot support (some kinds of) dynamic relocations in 33575 read-only sections even in executables. 33576 33577 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 33578 RELOC, unsigned HOST_WIDE_INT ALIGN) 33579 Return the section into which EXP should be placed. You can 33580 assume that EXP is either a `VAR_DECL' node or a constant of some 33581 sort. RELOC indicates whether the initial value of EXP requires 33582 link-time relocations. Bit 0 is set when variable contains local 33583 relocations only, while bit 1 is set for global relocations. 33584 ALIGN is the constant alignment in bits. 33585 33586 The default version of this function takes care of putting 33587 read-only variables in `readonly_data_section'. 33588 33589 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 33590 33591 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 33592 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 33593 called for `FUNCTION_DECL's as well as for variables and constants. 33594 33595 In the case of a `FUNCTION_DECL', RELOC will be zero if the 33596 function has been determined to be likely to be called, and 33597 nonzero if it is unlikely to be called. 33598 33599 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 33600 Build up a unique section name, expressed as a `STRING_CST' node, 33601 and assign it to `DECL_SECTION_NAME (DECL)'. As with 33602 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 33603 value of EXP requires link-time relocations. 33604 33605 The default version of this function appends the symbol name to the 33606 ELF section name that would normally be used for the symbol. For 33607 example, the function `foo' would be placed in `.text.foo'. 33608 Whatever the actual target object format, this is often good 33609 enough. 33610 33611 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 33612 DECL) 33613 Return the readonly data section associated with 33614 `DECL_SECTION_NAME (DECL)'. The default version of this function 33615 selects `.gnu.linkonce.r.name' if the function's section is 33616 `.gnu.linkonce.t.name', `.rodata.name' if function is in 33617 `.text.name', and the normal readonly-data section otherwise. 33618 33619 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 33620 Usually, the compiler uses the prefix `".rodata"' to construct 33621 section names for mergeable constant data. Define this macro to 33622 override the string if a different section name should be used. 33623 33624 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 33625 Return the section that should be used for transactional memory 33626 clone tables. 33627 33628 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum 33629 machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 33630 Return the section into which a constant X, of mode MODE, should 33631 be placed. You can assume that X is some kind of constant in RTL. 33632 The argument MODE is redundant except in the case of a `const_int' 33633 rtx. ALIGN is the constant alignment in bits. 33634 33635 The default version of this function takes care of putting symbolic 33636 constants in `flag_pic' mode in `data_section' and everything else 33637 in `readonly_data_section'. 33638 33639 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, 33640 tree ID) 33641 Define this hook if you need to postprocess the assembler name 33642 generated by target-independent code. The ID provided to this 33643 hook will be the computed name (e.g., the macro `DECL_NAME' of the 33644 DECL in C, or the mangled name of the DECL in C++). The return 33645 value of the hook is an `IDENTIFIER_NODE' for the appropriate 33646 mangled name on your target system. The default implementation of 33647 this hook just returns the ID provided. 33648 33649 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 33650 int NEW_DECL_P) 33651 Define this hook if references to a symbol or a constant must be 33652 treated differently depending on something about the variable or 33653 function named by the symbol (such as what section it is in). 33654 33655 The hook is executed immediately after rtl has been created for 33656 DECL, which may be a variable or function declaration or an entry 33657 in the constant pool. In either case, RTL is the rtl in question. 33658 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not 33659 have been initialized yet. 33660 33661 In the case of a constant, it is safe to assume that the rtl is a 33662 `mem' whose address is a `symbol_ref'. Most decls will also have 33663 this form, but that is not guaranteed. Global register variables, 33664 for instance, will have a `reg' for their rtl. (Normally the 33665 right thing to do with such unusual rtl is leave it alone.) 33666 33667 The NEW_DECL_P argument will be true if this is the first time 33668 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. 33669 It will be false for subsequent invocations, which will happen for 33670 duplicate declarations. Whether or not anything must be done for 33671 the duplicate declaration depends on whether the hook examines 33672 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 33673 called for a constant. 33674 33675 The usual thing for this hook to do is to record flags in the 33676 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'. 33677 Historically, the name string was modified if it was necessary to 33678 encode more than one bit of information, but this practice is now 33679 discouraged; use `SYMBOL_REF_FLAGS'. 33680 33681 The default definition of this hook, `default_encode_section_info' 33682 in `varasm.c', sets a number of commonly-useful bits in 33683 `SYMBOL_REF_FLAGS'. Check whether the default does what you need 33684 before overriding it. 33685 33686 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 33687 *NAME) 33688 Decode NAME and return the real name part, sans the characters 33689 that `TARGET_ENCODE_SECTION_INFO' may have added. 33690 33691 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 33692 Returns true if EXP should be placed into a "small data" section. 33693 The default version of this hook always returns false. 33694 33695 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 33696 Contains the value true if the target places read-only "small 33697 data" into a separate section. The default value is false. 33698 33699 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 33700 It returns true if target wants profile code emitted before 33701 prologue. 33702 33703 The default version of this hook use the target macro 33704 `PROFILE_BEFORE_PROLOGUE'. 33705 33706 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 33707 Returns true if EXP names an object for which name resolution 33708 rules must resolve to the current "module" (dynamic shared library 33709 or executable image). 33710 33711 The default version of this hook implements the name resolution 33712 rules for ELF, which has a looser model of global name binding 33713 than other currently supported object file formats. 33714 33715 -- Target Hook: bool TARGET_HAVE_TLS 33716 Contains the value true if the target supports thread-local 33717 storage. The default value is false. 33718 33719 33720File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 33721 3372217.20 Position Independent Code 33723=============================== 33724 33725This section describes macros that help implement generation of position 33726independent code. Simply defining these macros is not enough to 33727generate valid PIC; you must also add support to the hook 33728`TARGET_LEGITIMATE_ADDRESS_P' and to the macro `PRINT_OPERAND_ADDRESS', 33729as well as `LEGITIMIZE_ADDRESS'. You must modify the definition of 33730`movsi' to do something appropriate when the source operand contains a 33731symbolic address. You may also need to alter the handling of switch 33732statements so that they use relative addresses. 33733 33734 -- Macro: PIC_OFFSET_TABLE_REGNUM 33735 The register number of the register used to address a table of 33736 static data addresses in memory. In some cases this register is 33737 defined by a processor's "application binary interface" (ABI). 33738 When this macro is defined, RTL is generated for this register 33739 once, as with the stack pointer and frame pointer registers. If 33740 this macro is not defined, it is up to the machine-dependent files 33741 to allocate such a register (if necessary). Note that this 33742 register must be fixed when in use (e.g. when `flag_pic' is true). 33743 33744 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 33745 A C expression that is nonzero if the register defined by 33746 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 33747 the default is zero. Do not define this macro if 33748 `PIC_OFFSET_TABLE_REGNUM' is not defined. 33749 33750 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 33751 A C expression that is nonzero if X is a legitimate immediate 33752 operand on the target machine when generating position independent 33753 code. You can assume that X satisfies `CONSTANT_P', so you need 33754 not check this. You can also assume FLAG_PIC is true, so you need 33755 not check it either. You need not define this macro if all 33756 constants (including `SYMBOL_REF') can be immediate operands when 33757 generating position independent code. 33758 33759 33760File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 33761 3376217.21 Defining the Output Assembler Language 33763============================================ 33764 33765This section describes macros whose principal purpose is to describe how 33766to write instructions in assembler language--rather than what the 33767instructions do. 33768 33769* Menu: 33770 33771* File Framework:: Structural information for the assembler file. 33772* Data Output:: Output of constants (numbers, strings, addresses). 33773* Uninitialized Data:: Output of uninitialized variables. 33774* Label Output:: Output and generation of labels. 33775* Initialization:: General principles of initialization 33776 and termination routines. 33777* Macros for Initialization:: 33778 Specific macros that control the handling of 33779 initialization and termination routines. 33780* Instruction Output:: Output of actual instructions. 33781* Dispatch Tables:: Output of jump tables. 33782* Exception Region Output:: Output of exception region code. 33783* Alignment Output:: Pseudo ops for alignment and skipping data. 33784 33785 33786File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 33787 3378817.21.1 The Overall Framework of an Assembler File 33789-------------------------------------------------- 33790 33791This describes the overall framework of an assembly file. 33792 33793 -- Target Hook: void TARGET_ASM_FILE_START (void) 33794 Output to `asm_out_file' any text which the assembler expects to 33795 find at the beginning of a file. The default behavior is 33796 controlled by two flags, documented below. Unless your target's 33797 assembler is quite unusual, if you override the default, you 33798 should call `default_file_start' at some point in your target 33799 hook. This lets other target files rely on these variables. 33800 33801 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 33802 If this flag is true, the text of the macro `ASM_APP_OFF' will be 33803 printed as the very first line in the assembly file, unless 33804 `-fverbose-asm' is in effect. (If that macro has been defined to 33805 the empty string, this variable has no effect.) With the normal 33806 definition of `ASM_APP_OFF', the effect is to notify the GNU 33807 assembler that it need not bother stripping comments or extra 33808 whitespace from its input. This allows it to work a bit faster. 33809 33810 The default is false. You should not set it to true unless you 33811 have verified that your port does not generate any extra 33812 whitespace or comments that will cause GAS to issue errors in 33813 NO_APP mode. 33814 33815 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 33816 If this flag is true, `output_file_directive' will be called for 33817 the primary source file, immediately after printing `ASM_APP_OFF' 33818 (if that is enabled). Most ELF assemblers expect this to be done. 33819 The default is false. 33820 33821 -- Target Hook: void TARGET_ASM_FILE_END (void) 33822 Output to `asm_out_file' any text which the assembler expects to 33823 find at the end of a file. The default is to output nothing. 33824 33825 -- Function: void file_end_indicate_exec_stack () 33826 Some systems use a common convention, the `.note.GNU-stack' 33827 special section, to indicate whether or not an object file relies 33828 on the stack being executable. If your system uses this 33829 convention, you should define `TARGET_ASM_FILE_END' to this 33830 function. If you need to do other things in that hook, have your 33831 hook function call this function. 33832 33833 -- Target Hook: void TARGET_ASM_LTO_START (void) 33834 Output to `asm_out_file' any text which the assembler expects to 33835 find at the start of an LTO section. The default is to output 33836 nothing. 33837 33838 -- Target Hook: void TARGET_ASM_LTO_END (void) 33839 Output to `asm_out_file' any text which the assembler expects to 33840 find at the end of an LTO section. The default is to output 33841 nothing. 33842 33843 -- Target Hook: void TARGET_ASM_CODE_END (void) 33844 Output to `asm_out_file' any text which is needed before emitting 33845 unwind info and debug info at the end of a file. Some targets emit 33846 here PIC setup thunks that cannot be emitted at the end of file, 33847 because they couldn't have unwind info then. The default is to 33848 output nothing. 33849 33850 -- Macro: ASM_COMMENT_START 33851 A C string constant describing how to begin a comment in the target 33852 assembler language. The compiler assumes that the comment will 33853 end at the end of the line. 33854 33855 -- Macro: ASM_APP_ON 33856 A C string constant for text to be output before each `asm' 33857 statement or group of consecutive ones. Normally this is 33858 `"#APP"', which is a comment that has no effect on most assemblers 33859 but tells the GNU assembler that it must check the lines that 33860 follow for all valid assembler constructs. 33861 33862 -- Macro: ASM_APP_OFF 33863 A C string constant for text to be output after each `asm' 33864 statement or group of consecutive ones. Normally this is 33865 `"#NO_APP"', which tells the GNU assembler to resume making the 33866 time-saving assumptions that are valid for ordinary compiler 33867 output. 33868 33869 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 33870 A C statement to output COFF information or DWARF debugging 33871 information which indicates that filename NAME is the current 33872 source file to the stdio stream STREAM. 33873 33874 This macro need not be defined if the standard form of output for 33875 the file format in use is appropriate. 33876 33877 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 33878 const char *NAME) 33879 Output COFF information or DWARF debugging information which 33880 indicates that filename NAME is the current source file to the 33881 stdio stream FILE. 33882 33883 This target hook need not be defined if the standard form of 33884 output for the file format in use is appropriate. 33885 33886 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 33887 Output a string based on NAME, suitable for the `#ident' 33888 directive, or the equivalent directive or pragma in non-C-family 33889 languages. If this hook is not defined, nothing is output for the 33890 `#ident' directive. 33891 33892 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 33893 A C statement to output the string STRING to the stdio stream 33894 STREAM. If you do not call the function `output_quoted_string' in 33895 your config files, GCC will only call it to output filenames to 33896 the assembler source. So you can use it to canonicalize the format 33897 of the filename using this macro. 33898 33899 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 33900 unsigned int FLAGS, tree DECL) 33901 Output assembly directives to switch to section NAME. The section 33902 should have attributes as specified by FLAGS, which is a bit mask 33903 of the `SECTION_*' flags defined in `output.h'. If DECL is 33904 non-NULL, it is the `VAR_DECL' or `FUNCTION_DECL' with which this 33905 section is associated. 33906 33907 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 33908 node_frequency FREQ, bool STARTUP, bool EXIT) 33909 Return preferred text (sub)section for function DECL. Main 33910 purpose of this function is to separate cold, normal and hot 33911 functions. STARTUP is true when function is known to be used only 33912 at startup (from static constructors or it is `main()'). EXIT is 33913 true when function is known to be used only at exit (from static 33914 destructors). Return NULL if function should go to default text 33915 section. 33916 33917 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 33918 *FILE, tree DECL, bool NEW_IS_COLD) 33919 Used by the target to emit any assembler directives or additional 33920 labels needed when a function is partitioned between different 33921 sections. Output should be written to FILE. The function decl 33922 is available as DECL and the new section is `cold' if NEW_IS_COLD 33923 is `true'. 33924 33925 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 33926 This flag is true if the target supports 33927 `TARGET_ASM_NAMED_SECTION'. It must not be modified by 33928 command-line option processing. 33929 33930 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 33931 This flag is true if we can create zeroed data by switching to a 33932 BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space. 33933 This is true on most ELF targets. 33934 33935 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 33936 const char *NAME, int RELOC) 33937 Choose a set of section attributes for use by 33938 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 33939 section name, and whether or not the declaration's initializer may 33940 contain runtime relocations. DECL may be null, in which case 33941 read-write data should be assumed. 33942 33943 The default version of this function handles choosing code vs data, 33944 read-only vs read-write data, and `flag_pic'. You should only 33945 need to override this if your target has special flags that might 33946 be set via `__attribute__'. 33947 33948 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 33949 TYPE, const char *TEXT) 33950 Provides the target with the ability to record the gcc command line 33951 switches that have been passed to the compiler, and options that 33952 are enabled. The TYPE argument specifies what is being recorded. 33953 It can take the following values: 33954 33955 `SWITCH_TYPE_PASSED' 33956 TEXT is a command line switch that has been set by the user. 33957 33958 `SWITCH_TYPE_ENABLED' 33959 TEXT is an option which has been enabled. This might be as a 33960 direct result of a command line switch, or because it is 33961 enabled by default or because it has been enabled as a side 33962 effect of a different command line switch. For example, the 33963 `-O2' switch enables various different individual 33964 optimization passes. 33965 33966 `SWITCH_TYPE_DESCRIPTIVE' 33967 TEXT is either NULL or some descriptive text which should be 33968 ignored. If TEXT is NULL then it is being used to warn the 33969 target hook that either recording is starting or ending. The 33970 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 33971 the warning is for start up and the second time the warning 33972 is for wind down. This feature is to allow the target hook 33973 to make any necessary preparations before it starts to record 33974 switches and to perform any necessary tidying up after it has 33975 finished recording switches. 33976 33977 `SWITCH_TYPE_LINE_START' 33978 This option can be ignored by this target hook. 33979 33980 `SWITCH_TYPE_LINE_END' 33981 This option can be ignored by this target hook. 33982 33983 The hook's return value must be zero. Other return values may be 33984 supported in the future. 33985 33986 By default this hook is set to NULL, but an example implementation 33987 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 33988 it records the switches as ASCII text inside a new, string 33989 mergeable section in the assembler output file. The name of the 33990 new section is provided by the 33991 `TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 33992 33993 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 33994 This is the name of the section that will be created by the example 33995 ELF implementation of the `TARGET_ASM_RECORD_GCC_SWITCHES' target 33996 hook. 33997 33998 33999File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 34000 3400117.21.2 Output of Data 34002---------------------- 34003 34004 -- Target Hook: const char * TARGET_ASM_BYTE_OP 34005 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 34006 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 34007 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 34008 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 34009 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 34010 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 34011 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 34012 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 34013 These hooks specify assembly directives for creating certain kinds 34014 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a 34015 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an 34016 aligned two-byte object, and so on. Any of the hooks may be 34017 `NULL', indicating that no suitable directive is available. 34018 34019 The compiler will print these strings at the start of a new line, 34020 followed immediately by the object's initial value. In most cases, 34021 the string should contain a tab, a pseudo-op, and then another tab. 34022 34023 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 34024 ALIGNED_P) 34025 The `assemble_integer' function uses this hook to output an 34026 integer object. X is the object's value, SIZE is its size in 34027 bytes and ALIGNED_P indicates whether it is aligned. The function 34028 should return `true' if it was able to output the object. If it 34029 returns false, `assemble_integer' will try to split the object 34030 into smaller parts. 34031 34032 The default implementation of this hook will use the 34033 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the 34034 relevant string is `NULL'. 34035 34036 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 34037 rtx X) 34038 A target hook to recognize RTX patterns that `output_addr_const' 34039 can't deal with, and output assembly code to FILE corresponding to 34040 the pattern X. This may be used to allow machine-dependent 34041 `UNSPEC's to appear within constants. 34042 34043 If target hook fails to recognize a pattern, it must return 34044 `false', so that a standard error message is printed. If it 34045 prints an error message itself, by calling, for example, 34046 `output_operand_lossage', it may just return `true'. 34047 34048 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 34049 A C statement to output to the stdio stream STREAM an assembler 34050 instruction to assemble a string constant containing the LEN bytes 34051 at PTR. PTR will be a C expression of type `char *' and LEN a C 34052 expression of type `int'. 34053 34054 If the assembler has a `.ascii' pseudo-op as found in the Berkeley 34055 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 34056 34057 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 34058 A C statement to output word N of a function descriptor for DECL. 34059 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is 34060 defined, and is otherwise unused. 34061 34062 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 34063 You may define this macro as a C expression. You should define the 34064 expression to have a nonzero value if GCC should output the 34065 constant pool for a function before the code for the function, or 34066 a zero value if GCC should output the constant pool after the 34067 function. If you do not define this macro, the usual case, GCC 34068 will output the constant pool before the function. 34069 34070 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 34071 A C statement to output assembler commands to define the start of 34072 the constant pool for a function. FUNNAME is a string giving the 34073 name of the function. Should the return type of the function be 34074 required, it can be obtained via FUNDECL. SIZE is the size, in 34075 bytes, of the constant pool that will be written immediately after 34076 this call. 34077 34078 If no constant-pool prefix is required, the usual case, this macro 34079 need not be defined. 34080 34081 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, 34082 LABELNO, JUMPTO) 34083 A C statement (with or without semicolon) to output a constant in 34084 the constant pool, if it needs special treatment. (This macro 34085 need not do anything for RTL expressions that can be output 34086 normally.) 34087 34088 The argument FILE is the standard I/O stream to output the 34089 assembler code on. X is the RTL expression for the constant to 34090 output, and MODE is the machine mode (in case X is a `const_int'). 34091 ALIGN is the required alignment for the value X; you should output 34092 an assembler directive to force this much alignment. 34093 34094 The argument LABELNO is a number to use in an internal label for 34095 the address of this pool entry. The definition of this macro is 34096 responsible for outputting the label definition at the proper 34097 place. Here is how to do this: 34098 34099 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO); 34100 34101 When you output a pool entry specially, you should end with a 34102 `goto' to the label JUMPTO. This will prevent the same pool entry 34103 from being output a second time in the usual manner. 34104 34105 You need not define this macro if it would do nothing. 34106 34107 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 34108 A C statement to output assembler commands to at the end of the 34109 constant pool for a function. FUNNAME is a string giving the name 34110 of the function. Should the return type of the function be 34111 required, you can obtain it via FUNDECL. SIZE is the size, in 34112 bytes, of the constant pool that GCC wrote immediately before this 34113 call. 34114 34115 If no constant-pool epilogue is required, the usual case, you need 34116 not define this macro. 34117 34118 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 34119 Define this macro as a C expression which is nonzero if C is used 34120 as a logical line separator by the assembler. STR points to the 34121 position in the string where C was found; this can be used if a 34122 line separator uses multiple characters. 34123 34124 If you do not define this macro, the default is that only the 34125 character `;' is treated as a logical line separator. 34126 34127 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 34128 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 34129 These target hooks are C string constants, describing the syntax 34130 in the assembler for grouping arithmetic expressions. If not 34131 overridden, they default to normal parentheses, which is correct 34132 for most assemblers. 34133 34134 These macros are provided by `real.h' for writing the definitions of 34135`ASM_OUTPUT_DOUBLE' and the like: 34136 34137 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 34138 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 34139 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 34140 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 34141 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 34142 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 34143 These translate X, of type `REAL_VALUE_TYPE', to the target's 34144 floating point representation, and store its bit pattern in the 34145 variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and 34146 `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 34147 `long int'. For the others, it should be an array of `long int'. 34148 The number of elements in this array is determined by the size of 34149 the desired target floating point data type: 32 bits of it go in 34150 each `long int' array element. Each array element holds 32 bits 34151 of the result, even if `long int' is wider than 32 bits on the 34152 host machine. 34153 34154 The array element values are designed so that you can print them 34155 out using `fprintf' in the order they should appear in the target 34156 machine's memory. 34157 34158 34159File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 34160 3416117.21.3 Output of Uninitialized Variables 34162----------------------------------------- 34163 34164Each of the macros in this section is used to do the whole job of 34165outputting a single uninitialized variable. 34166 34167 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 34168 A C statement (sans semicolon) to output to the stdio stream 34169 STREAM the assembler definition of a common-label named NAME whose 34170 size is SIZE bytes. The variable ROUNDED is the size rounded up 34171 to whatever alignment the caller wants. It is possible that SIZE 34172 may be zero, for instance if a struct with no other member than a 34173 zero-length array is defined. In this case, the backend must 34174 output a symbol definition that allocates at least one byte, both 34175 so that the address of the resulting object does not compare equal 34176 to any other, and because some object formats cannot even express 34177 the concept of a zero-sized common symbol, as that is how they 34178 represent an ordinary undefined external. 34179 34180 Use the expression `assemble_name (STREAM, NAME)' to output the 34181 name itself; before and after that, output the additional 34182 assembler syntax for defining the name, and a newline. 34183 34184 This macro controls how the assembler definitions of uninitialized 34185 common global variables are output. 34186 34187 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 34188 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a 34189 separate, explicit argument. If you define this macro, it is used 34190 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in 34191 handling the required alignment of the variable. The alignment is 34192 specified as the number of bits. 34193 34194 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 34195 ALIGNMENT) 34196 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 34197 to be output, if there is one, or `NULL_TREE' if there is no 34198 corresponding variable. If you define this macro, GCC will use it 34199 in place of both `ASM_OUTPUT_COMMON' and 34200 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 34201 see the variable's decl in order to chose what to output. 34202 34203 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 34204 A C statement (sans semicolon) to output to the stdio stream 34205 STREAM the assembler definition of uninitialized global DECL named 34206 NAME whose size is SIZE bytes. The variable ALIGNMENT is the 34207 alignment specified as the number of bits. 34208 34209 Try to use function `asm_output_aligned_bss' defined in file 34210 `varasm.c' when defining this macro. If unable, use the expression 34211 `assemble_name (STREAM, NAME)' to output the name itself; before 34212 and after that, output the additional assembler syntax for defining 34213 the name, and a newline. 34214 34215 There are two ways of handling global BSS. One is to define this 34216 macro. The other is to have `TARGET_ASM_SELECT_SECTION' return a 34217 switchable BSS section (*note 34218 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 34219 both. 34220 34221 Some languages do not have `common' data, and require a non-common 34222 form of global BSS in order to handle uninitialized globals 34223 efficiently. C++ is one example of this. However, if the target 34224 does not support global BSS, the front end may choose to make 34225 globals common in order to save space in the object file. 34226 34227 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 34228 A C statement (sans semicolon) to output to the stdio stream 34229 STREAM the assembler definition of a local-common-label named NAME 34230 whose size is SIZE bytes. The variable ROUNDED is the size 34231 rounded up to whatever alignment the caller wants. 34232 34233 Use the expression `assemble_name (STREAM, NAME)' to output the 34234 name itself; before and after that, output the additional 34235 assembler syntax for defining the name, and a newline. 34236 34237 This macro controls how the assembler definitions of uninitialized 34238 static variables are output. 34239 34240 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 34241 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a 34242 separate, explicit argument. If you define this macro, it is used 34243 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in 34244 handling the required alignment of the variable. The alignment is 34245 specified as the number of bits. 34246 34247 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 34248 ALIGNMENT) 34249 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 34250 be output, if there is one, or `NULL_TREE' if there is no 34251 corresponding variable. If you define this macro, GCC will use it 34252 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'. 34253 Define this macro when you need to see the variable's decl in 34254 order to chose what to output. 34255 34256 34257File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 34258 3425917.21.4 Output and Generation of Labels 34260--------------------------------------- 34261 34262This is about outputting labels. 34263 34264 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 34265 A C statement (sans semicolon) to output to the stdio stream 34266 STREAM the assembler definition of a label named NAME. Use the 34267 expression `assemble_name (STREAM, NAME)' to output the name 34268 itself; before and after that, output the additional assembler 34269 syntax for defining the name, and a newline. A default definition 34270 of this macro is provided which is correct for most systems. 34271 34272 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 34273 A C statement (sans semicolon) to output to the stdio stream 34274 STREAM the assembler definition of a label named NAME of a 34275 function. Use the expression `assemble_name (STREAM, NAME)' to 34276 output the name itself; before and after that, output the 34277 additional assembler syntax for defining the name, and a newline. 34278 A default definition of this macro is provided which is correct 34279 for most systems. 34280 34281 If this macro is not defined, then the function name is defined in 34282 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 34283 34284 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 34285 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to 34286 refer to a compiler-generated label. The default definition uses 34287 `assemble_name_raw', which is like `assemble_name' except that it 34288 is more efficient. 34289 34290 -- Macro: SIZE_ASM_OP 34291 A C string containing the appropriate assembler directive to 34292 specify the size of a symbol, without any arguments. On systems 34293 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"'; 34294 on other systems, the default is not to define this macro. 34295 34296 Define this macro only if it is correct to use the default 34297 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and 34298 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 34299 custom definitions of those macros, or if you do not need explicit 34300 symbol sizes at all, do not define this macro. 34301 34302 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 34303 A C statement (sans semicolon) to output to the stdio stream 34304 STREAM a directive telling the assembler that the size of the 34305 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define 34306 `SIZE_ASM_OP', a default definition of this macro is provided. 34307 34308 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 34309 A C statement (sans semicolon) to output to the stdio stream 34310 STREAM a directive telling the assembler to calculate the size of 34311 the symbol NAME by subtracting its address from the current 34312 address. 34313 34314 If you define `SIZE_ASM_OP', a default definition of this macro is 34315 provided. The default assumes that the assembler recognizes a 34316 special `.' symbol as referring to the current address, and can 34317 calculate the difference between this and another symbol. If your 34318 assembler does not recognize `.' or cannot do calculations with 34319 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use 34320 some other technique. 34321 34322 -- Macro: NO_DOLLAR_IN_LABEL 34323 Define this macro if the assembler does not accept the character 34324 `$' in label names. By default constructors and destructors in 34325 G++ have `$' in the identifiers. If this macro is defined, `.' is 34326 used instead. 34327 34328 -- Macro: NO_DOT_IN_LABEL 34329 Define this macro if the assembler does not accept the character 34330 `.' in label names. By default constructors and destructors in G++ 34331 have names that use `.'. If this macro is defined, these names 34332 are rewritten to avoid `.'. 34333 34334 -- Macro: TYPE_ASM_OP 34335 A C string containing the appropriate assembler directive to 34336 specify the type of a symbol, without any arguments. On systems 34337 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"'; 34338 on other systems, the default is not to define this macro. 34339 34340 Define this macro only if it is correct to use the default 34341 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 34342 need your own custom definition of this macro, or if you do not 34343 need explicit symbol types at all, do not define this macro. 34344 34345 -- Macro: TYPE_OPERAND_FMT 34346 A C string which specifies (using `printf' syntax) the format of 34347 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the 34348 default (in `config/elfos.h') is `"@%s"'; on other systems, the 34349 default is not to define this macro. 34350 34351 Define this macro only if it is correct to use the default 34352 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 34353 need your own custom definition of this macro, or if you do not 34354 need explicit symbol types at all, do not define this macro. 34355 34356 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 34357 A C statement (sans semicolon) to output to the stdio stream 34358 STREAM a directive telling the assembler that the type of the 34359 symbol NAME is TYPE. TYPE is a C string; currently, that string 34360 is always either `"function"' or `"object"', but you should not 34361 count on this. 34362 34363 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default 34364 definition of this macro is provided. 34365 34366 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 34367 A C statement (sans semicolon) to output to the stdio stream 34368 STREAM any text necessary for declaring the name NAME of a 34369 function which is being defined. This macro is responsible for 34370 outputting the label definition (perhaps using 34371 `ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 34372 `FUNCTION_DECL' tree node representing the function. 34373 34374 If this macro is not defined, then the function name is defined in 34375 the usual manner as a label (by means of 34376 `ASM_OUTPUT_FUNCTION_LABEL'). 34377 34378 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 34379 of this macro. 34380 34381 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 34382 A C statement (sans semicolon) to output to the stdio stream 34383 STREAM any text necessary for declaring the size of a function 34384 which is being defined. The argument NAME is the name of the 34385 function. The argument DECL is the `FUNCTION_DECL' tree node 34386 representing the function. 34387 34388 If this macro is not defined, then the function size is not 34389 defined. 34390 34391 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition 34392 of this macro. 34393 34394 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 34395 A C statement (sans semicolon) to output to the stdio stream 34396 STREAM any text necessary for declaring the name NAME of an 34397 initialized variable which is being defined. This macro must 34398 output the label definition (perhaps using `ASM_OUTPUT_LABEL'). 34399 The argument DECL is the `VAR_DECL' tree node representing the 34400 variable. 34401 34402 If this macro is not defined, then the variable name is defined in 34403 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 34404 34405 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or 34406 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 34407 34408 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 34409 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 34410 A target hook to output to the stdio stream FILE any text necessary 34411 for declaring the name NAME of a constant which is being defined. 34412 This target hook is responsible for outputting the label 34413 definition (perhaps using `assemble_label'). The argument EXP is 34414 the value of the constant, and SIZE is the size of the constant in 34415 bytes. The NAME will be an internal label. 34416 34417 The default version of this target hook, define the NAME in the 34418 usual manner as a label (by means of `assemble_label'). 34419 34420 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in this target 34421 hook. 34422 34423 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 34424 A C statement (sans semicolon) to output to the stdio stream 34425 STREAM any text necessary for claiming a register REGNO for a 34426 global variable DECL with name NAME. 34427 34428 If you don't define this macro, that is equivalent to defining it 34429 to do nothing. 34430 34431 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 34432 A C statement (sans semicolon) to finish up declaring a variable 34433 name once the compiler has processed its initializer fully and 34434 thus has had a chance to determine the size of an array when 34435 controlled by an initializer. This is used on systems where it's 34436 necessary to declare something about the size of the object. 34437 34438 If you don't define this macro, that is equivalent to defining it 34439 to do nothing. 34440 34441 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or 34442 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 34443 34444 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 34445 char *NAME) 34446 This target hook is a function to output to the stdio stream 34447 STREAM some commands that will make the label NAME global; that 34448 is, available for reference from other files. 34449 34450 The default implementation relies on a proper definition of 34451 `GLOBAL_ASM_OP'. 34452 34453 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, 34454 tree DECL) 34455 This target hook is a function to output to the stdio stream 34456 STREAM some commands that will make the name associated with DECL 34457 global; that is, available for reference from other files. 34458 34459 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 34460 target hook. 34461 34462 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 34463 A C statement (sans semicolon) to output to the stdio stream 34464 STREAM some commands that will make the label NAME weak; that is, 34465 available for reference from other files but only used if no other 34466 definition is available. Use the expression `assemble_name 34467 (STREAM, NAME)' to output the name itself; before and after that, 34468 output the additional assembler syntax for making that name weak, 34469 and a newline. 34470 34471 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not 34472 support weak symbols and you should not define the `SUPPORTS_WEAK' 34473 macro. 34474 34475 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 34476 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and 34477 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 34478 or variable decl. If VALUE is not `NULL', this C statement should 34479 output to the stdio stream STREAM assembler code which defines 34480 (equates) the weak symbol NAME to have the value VALUE. If VALUE 34481 is `NULL', it should output commands to make NAME weak. 34482 34483 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 34484 Outputs a directive that enables NAME to be used to refer to 34485 symbol VALUE with weak-symbol semantics. `decl' is the 34486 declaration of `name'. 34487 34488 -- Macro: SUPPORTS_WEAK 34489 A preprocessor constant expression which evaluates to true if the 34490 target supports weak symbols. 34491 34492 If you don't define this macro, `defaults.h' provides a default 34493 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is 34494 defined, the default definition is `1'; otherwise, it is `0'. 34495 34496 -- Macro: TARGET_SUPPORTS_WEAK 34497 A C expression which evaluates to true if the target supports weak 34498 symbols. 34499 34500 If you don't define this macro, `defaults.h' provides a default 34501 definition. The default definition is `(SUPPORTS_WEAK)'. Define 34502 this macro if you want to control weak symbol support with a 34503 compiler flag such as `-melf'. 34504 34505 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 34506 A C statement (sans semicolon) to mark DECL to be emitted as a 34507 public symbol such that extra copies in multiple translation units 34508 will be discarded by the linker. Define this macro if your object 34509 file format provides support for this concept, such as the `COMDAT' 34510 section flags in the Microsoft Windows PE/COFF format, and this 34511 support requires changes to DECL, such as putting it in a separate 34512 section. 34513 34514 -- Macro: SUPPORTS_ONE_ONLY 34515 A C expression which evaluates to true if the target supports 34516 one-only semantics. 34517 34518 If you don't define this macro, `varasm.c' provides a default 34519 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default 34520 definition is `1'; otherwise, it is `0'. Define this macro if you 34521 want to control one-only symbol support with a compiler flag, or if 34522 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to 34523 be emitted as one-only. 34524 34525 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 34526 VISIBILITY) 34527 This target hook is a function to output to ASM_OUT_FILE some 34528 commands that will make the symbol(s) associated with DECL have 34529 hidden, protected or internal visibility as specified by 34530 VISIBILITY. 34531 34532 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 34533 A C expression that evaluates to true if the target's linker 34534 expects that weak symbols do not appear in a static archive's 34535 table of contents. The default is `0'. 34536 34537 Leaving weak symbols out of an archive's table of contents means 34538 that, if a symbol will only have a definition in one translation 34539 unit and will have undefined references from other translation 34540 units, that symbol should not be weak. Defining this macro to be 34541 nonzero will thus have the effect that certain symbols that would 34542 normally be weak (explicit template instantiations, and vtables 34543 for polymorphic classes with noninline key methods) will instead 34544 be nonweak. 34545 34546 The C++ ABI requires this macro to be zero. Define this macro for 34547 targets where full C++ ABI compliance is impossible and where 34548 linker restrictions require weak symbols to be left out of a 34549 static archive's table of contents. 34550 34551 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 34552 A C statement (sans semicolon) to output to the stdio stream 34553 STREAM any text necessary for declaring the name of an external 34554 symbol named NAME which is referenced in this compilation but not 34555 defined. The value of DECL is the tree node for the declaration. 34556 34557 This macro need not be defined if it does not need to output 34558 anything. The GNU assembler and most Unix assemblers don't 34559 require anything. 34560 34561 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 34562 This target hook is a function to output to ASM_OUT_FILE an 34563 assembler pseudo-op to declare a library function name external. 34564 The name of the library function is given by SYMREF, which is a 34565 `symbol_ref'. 34566 34567 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 34568 *SYMBOL) 34569 This target hook is a function to output to ASM_OUT_FILE an 34570 assembler directive to annotate SYMBOL as used. The Darwin target 34571 uses the .no_dead_code_strip directive. 34572 34573 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 34574 A C statement (sans semicolon) to output to the stdio stream 34575 STREAM a reference in assembler syntax to a label named NAME. 34576 This should add `_' to the front of the name, if that is customary 34577 on your operating system, as it is in most Berkeley Unix systems. 34578 This macro is used in `assemble_name'. 34579 34580 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 34581 Given a symbol NAME, perform same mangling as `varasm.c''s 34582 `assemble_name', but in memory rather than to a file stream, 34583 returning result as an `IDENTIFIER_NODE'. Required for correct 34584 LTO symtabs. The default implementation calls the 34585 `TARGET_STRIP_NAME_ENCODING' hook and then prepends the 34586 `USER_LABEL_PREFIX', if any. 34587 34588 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 34589 A C statement (sans semicolon) to output a reference to 34590 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to 34591 output the name of the symbol. This macro may be used to modify 34592 the way a symbol is referenced depending on information encoded by 34593 `TARGET_ENCODE_SECTION_INFO'. 34594 34595 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 34596 A C statement (sans semicolon) to output a reference to BUF, the 34597 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined, 34598 `assemble_name' will be used to output the name of the symbol. 34599 This macro is not used by `output_asm_label', or the `%l' 34600 specifier that calls it; the intention is that this macro should 34601 be set when it is necessary to output a label differently when its 34602 address is being taken. 34603 34604 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 34605 char *PREFIX, unsigned long LABELNO) 34606 A function to output to the stdio stream STREAM a label whose name 34607 is made from the string PREFIX and the number LABELNO. 34608 34609 It is absolutely essential that these labels be distinct from the 34610 labels used for user-level functions and variables. Otherwise, 34611 certain programs will have name conflicts with internal labels. 34612 34613 It is desirable to exclude internal labels from the symbol table 34614 of the object file. Most assemblers have a naming convention for 34615 labels that should be excluded; on many systems, the letter `L' at 34616 the beginning of a label has this effect. You should find out what 34617 convention your system uses, and follow it. 34618 34619 The default version of this function utilizes 34620 `ASM_GENERATE_INTERNAL_LABEL'. 34621 34622 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 34623 A C statement to output to the stdio stream STREAM a debug info 34624 label whose name is made from the string PREFIX and the number 34625 NUM. This is useful for VLIW targets, where debug info labels may 34626 need to be treated differently than branch target labels. On some 34627 systems, branch target labels must be at the beginning of 34628 instruction bundles, but debug info labels can occur in the middle 34629 of instruction bundles. 34630 34631 If this macro is not defined, then 34632 `(*targetm.asm_out.internal_label)' will be used. 34633 34634 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 34635 A C statement to store into the string STRING a label whose name 34636 is made from the string PREFIX and the number NUM. 34637 34638 This string, when output subsequently by `assemble_name', should 34639 produce the output that `(*targetm.asm_out.internal_label)' would 34640 produce with the same PREFIX and NUM. 34641 34642 If the string begins with `*', then `assemble_name' will output 34643 the rest of the string unchanged. It is often convenient for 34644 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the 34645 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to 34646 output the string, and may change it. (Of course, 34647 `ASM_OUTPUT_LABELREF' is also part of your machine description, so 34648 you should know what it does on your machine.) 34649 34650 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 34651 A C expression to assign to OUTVAR (which is a variable of type 34652 `char *') a newly allocated string made from the string NAME and 34653 the number NUMBER, with some suitable punctuation added. Use 34654 `alloca' to get space for the string. 34655 34656 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to 34657 produce an assembler label for an internal static variable whose 34658 name is NAME. Therefore, the string must be such as to result in 34659 valid assembler code. The argument NUMBER is different each time 34660 this macro is executed; it prevents conflicts between 34661 similarly-named internal static variables in different scopes. 34662 34663 Ideally this string should not be a valid C identifier, to prevent 34664 any conflict with the user's own symbols. Most assemblers allow 34665 periods or percent signs in assembler symbols; putting at least 34666 one of these between the name and the number will suffice. 34667 34668 If this macro is not defined, a default definition will be provided 34669 which is correct for most systems. 34670 34671 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 34672 A C statement to output to the stdio stream STREAM assembler code 34673 which defines (equates) the symbol NAME to have the value VALUE. 34674 34675 If `SET_ASM_OP' is defined, a default definition is provided which 34676 is correct for most systems. 34677 34678 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 34679 DECL_OF_VALUE) 34680 A C statement to output to the stdio stream STREAM assembler code 34681 which defines (equates) the symbol whose tree node is DECL_OF_NAME 34682 to have the value of the tree node DECL_OF_VALUE. This macro will 34683 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if 34684 the tree nodes are available. 34685 34686 If `SET_ASM_OP' is defined, a default definition is provided which 34687 is correct for most systems. 34688 34689 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 34690 A C statement that evaluates to true if the assembler code which 34691 defines (equates) the symbol whose tree node is DECL_OF_NAME to 34692 have the value of the tree node DECL_OF_VALUE should be emitted 34693 near the end of the current compilation unit. The default is to 34694 not defer output of defines. This macro affects defines output by 34695 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'. 34696 34697 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 34698 A C statement to output to the stdio stream STREAM assembler code 34699 which defines (equates) the weak symbol NAME to have the value 34700 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak 34701 symbol. 34702 34703 Define this macro if the target only supports weak aliases; define 34704 `ASM_OUTPUT_DEF' instead if possible. 34705 34706 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 34707 SEL_NAME) 34708 Define this macro to override the default assembler names used for 34709 Objective-C methods. 34710 34711 The default name is a unique method number followed by the name of 34712 the class (e.g. `_1_Foo'). For methods in categories, the name of 34713 the category is also included in the assembler name (e.g. 34714 `_1_Foo_Bar'). 34715 34716 These names are safe on most systems, but make debugging difficult 34717 since the method's selector is not present in the name. 34718 Therefore, particular systems define other ways of computing names. 34719 34720 BUF is an expression of type `char *' which gives you a buffer in 34721 which to store the name; its length is as long as CLASS_NAME, 34722 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 34723 34724 The argument IS_INST specifies whether the method is an instance 34725 method or a class method; CLASS_NAME is the name of the class; 34726 CAT_NAME is the name of the category (or `NULL' if the method is 34727 not in a category); and SEL_NAME is the name of the selector. 34728 34729 On systems where the assembler can handle quoted names, you can 34730 use this macro to provide more human-readable names. 34731 34732 34733File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 34734 3473517.21.5 How Initialization Functions Are Handled 34736------------------------------------------------ 34737 34738The compiled code for certain languages includes "constructors" (also 34739called "initialization routines")--functions to initialize data in the 34740program when the program is started. These functions need to be called 34741before the program is "started"--that is to say, before `main' is 34742called. 34743 34744 Compiling some languages generates "destructors" (also called 34745"termination routines") that should be called when the program 34746terminates. 34747 34748 To make the initialization and termination functions work, the compiler 34749must output something in the assembler code to cause those functions to 34750be called at the appropriate time. When you port the compiler to a new 34751system, you need to specify how to do this. 34752 34753 There are two major ways that GCC currently supports the execution of 34754initialization and termination functions. Each way has two variants. 34755Much of the structure is common to all four variations. 34756 34757 The linker must build two lists of these functions--a list of 34758initialization functions, called `__CTOR_LIST__', and a list of 34759termination functions, called `__DTOR_LIST__'. 34760 34761 Each list always begins with an ignored function pointer (which may 34762hold 0, -1, or a count of the function pointers after it, depending on 34763the environment). This is followed by a series of zero or more function 34764pointers to constructors (or destructors), followed by a function 34765pointer containing zero. 34766 34767 Depending on the operating system and its executable file format, 34768either `crtstuff.c' or `libgcc2.c' traverses these lists at startup 34769time and exit time. Constructors are called in reverse order of the 34770list; destructors in forward order. 34771 34772 The best way to handle static constructors works only for object file 34773formats which provide arbitrarily-named sections. A section is set 34774aside for a list of constructors, and another for a list of destructors. 34775Traditionally these are called `.ctors' and `.dtors'. Each object file 34776that defines an initialization function also puts a word in the 34777constructor section to point to that function. The linker accumulates 34778all these words into one contiguous `.ctors' section. Termination 34779functions are handled similarly. 34780 34781 This method will be chosen as the default by `target-def.h' if 34782`TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 34783arbitrary sections, but does support special designated constructor and 34784destructor sections may define `CTORS_SECTION_ASM_OP' and 34785`DTORS_SECTION_ASM_OP' to achieve the same effect. 34786 34787 When arbitrary sections are available, there are two variants, 34788depending upon how the code in `crtstuff.c' is called. On systems that 34789support a ".init" section which is executed at program startup, parts 34790of `crtstuff.c' are compiled into that section. The program is linked 34791by the `gcc' driver like this: 34792 34793 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 34794 34795 The prologue of a function (`__init') appears in the `.init' section 34796of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the 34797function `__fini' in the ".fini" section. Normally these files are 34798provided by the operating system or by the GNU C library, but are 34799provided by GCC for a few targets. 34800 34801 The objects `crtbegin.o' and `crtend.o' are (for most targets) 34802compiled from `crtstuff.c'. They contain, among other things, code 34803fragments within the `.init' and `.fini' sections that branch to 34804routines in the `.text' section. The linker will pull all parts of a 34805section together, which results in a complete `__init' function that 34806invokes the routines we need at startup. 34807 34808 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro 34809properly. 34810 34811 If no init section is available, when GCC compiles any function called 34812`main' (or more accurately, any function designated as a program entry 34813point by the language front end calling `expand_main_function'), it 34814inserts a procedure call to `__main' as the first executable code after 34815the function prologue. The `__main' function is defined in `libgcc2.c' 34816and runs the global constructors. 34817 34818 In file formats that don't support arbitrary sections, there are again 34819two variants. In the simplest variant, the GNU linker (GNU `ld') and 34820an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR' 34821is defined to produce a `.stabs' entry of type `N_SETT', referencing 34822the name `__CTOR_LIST__', and with the address of the void function 34823containing the initialization code as its value. The GNU linker 34824recognizes this as a request to add the value to a "set"; the values 34825are accumulated, and are eventually placed in the executable as a 34826vector in the format described above, with a leading (ignored) count 34827and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled 34828similarly. Since no init section is available, the absence of 34829`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' 34830as above, starting the initialization process. 34831 34832 The last variant uses neither arbitrary sections nor the GNU linker. 34833This is preferable when you want to do dynamic linking and when using 34834file formats which the GNU linker does not support, such as `ECOFF'. In 34835this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and 34836termination functions are recognized simply by their names. This 34837requires an extra program in the linkage step, called `collect2'. This 34838program pretends to be the linker, for use with GCC; it does its job by 34839running the ordinary linker, but also arranges to include the vectors of 34840initialization and termination functions. These functions are called 34841via `__main' as described above. In order to use this method, 34842`use_collect2' must be defined in the target in `config.gcc'. 34843 34844 The following section describes the specific macros that control and 34845customize the handling of initialization and termination functions. 34846 34847 34848File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 34849 3485017.21.6 Macros Controlling Initialization Routines 34851-------------------------------------------------- 34852 34853Here are the macros that control how the compiler handles initialization 34854and termination functions: 34855 34856 -- Macro: INIT_SECTION_ASM_OP 34857 If defined, a C string constant, including spacing, for the 34858 assembler operation to identify the following data as 34859 initialization code. If not defined, GCC will assume such a 34860 section does not exist. When you are using special sections for 34861 initialization and termination functions, this macro also controls 34862 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization 34863 functions. 34864 34865 -- Macro: HAS_INIT_SECTION 34866 If defined, `main' will not call `__main' as described above. 34867 This macro should be defined for systems that control start-up code 34868 on a symbol-by-symbol basis, such as OSF/1, and should not be 34869 defined explicitly for systems that support `INIT_SECTION_ASM_OP'. 34870 34871 -- Macro: LD_INIT_SWITCH 34872 If defined, a C string constant for a switch that tells the linker 34873 that the following symbol is an initialization routine. 34874 34875 -- Macro: LD_FINI_SWITCH 34876 If defined, a C string constant for a switch that tells the linker 34877 that the following symbol is a finalization routine. 34878 34879 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 34880 If defined, a C statement that will write a function that can be 34881 automatically called when a shared library is loaded. The function 34882 should call FUNC, which takes no arguments. If not defined, and 34883 the object format requires an explicit initialization function, 34884 then a function called `_GLOBAL__DI' will be generated. 34885 34886 This function and the following one are used by collect2 when 34887 linking a shared library that needs constructors or destructors, 34888 or has DWARF2 exception tables embedded in the code. 34889 34890 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 34891 If defined, a C statement that will write a function that can be 34892 automatically called when a shared library is unloaded. The 34893 function should call FUNC, which takes no arguments. If not 34894 defined, and the object format requires an explicit finalization 34895 function, then a function called `_GLOBAL__DD' will be generated. 34896 34897 -- Macro: INVOKE__main 34898 If defined, `main' will call `__main' despite the presence of 34899 `INIT_SECTION_ASM_OP'. This macro should be defined for systems 34900 where the init section is not actually run automatically, but is 34901 still useful for collecting the lists of constructors and 34902 destructors. 34903 34904 -- Macro: SUPPORTS_INIT_PRIORITY 34905 If nonzero, the C++ `init_priority' attribute is supported and the 34906 compiler should emit instructions to control the order of 34907 initialization of objects. If zero, the compiler will issue an 34908 error message upon encountering an `init_priority' attribute. 34909 34910 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 34911 This value is true if the target supports some "native" method of 34912 collecting constructors and destructors to be run at startup and 34913 exit. It is false if we must use `collect2'. 34914 34915 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 34916 If defined, a function that outputs assembler code to arrange to 34917 call the function referenced by SYMBOL at initialization time. 34918 34919 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no 34920 arguments and with no return value. If the target supports 34921 initialization priorities, PRIORITY is a value between 0 and 34922 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'. 34923 34924 If this macro is not defined by the target, a suitable default will 34925 be chosen if (1) the target supports arbitrary section names, (2) 34926 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2' 34927 is not defined. 34928 34929 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 34930 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination 34931 functions rather than initialization functions. 34932 34933 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 34934generated for the generated object file will have static linkage. 34935 34936 If your system uses `collect2' as the means of processing 34937constructors, then that program normally uses `nm' to scan an object 34938file for constructor functions to be called. 34939 34940 On certain kinds of systems, you can define this macro to make 34941`collect2' work faster (and, in some cases, make it work at all): 34942 34943 -- Macro: OBJECT_FORMAT_COFF 34944 Define this macro if the system uses COFF (Common Object File 34945 Format) object files, so that `collect2' can assume this format 34946 and scan object files directly for dynamic constructor/destructor 34947 functions. 34948 34949 This macro is effective only in a native compiler; `collect2' as 34950 part of a cross compiler always uses `nm' for the target machine. 34951 34952 -- Macro: REAL_NM_FILE_NAME 34953 Define this macro as a C string constant containing the file name 34954 to use to execute `nm'. The default is to search the path 34955 normally for `nm'. 34956 34957 -- Macro: NM_FLAGS 34958 `collect2' calls `nm' to scan object files for static constructors 34959 and destructors and LTO info. By default, `-n' is passed. Define 34960 `NM_FLAGS' to a C string constant if other options are needed to 34961 get the same output format as GNU `nm -n' produces. 34962 34963 If your system supports shared libraries and has a program to list the 34964dynamic dependencies of a given library or executable, you can define 34965these macros to enable support for running initialization and 34966termination functions in shared libraries: 34967 34968 -- Macro: LDD_SUFFIX 34969 Define this macro to a C string constant containing the name of 34970 the program which lists dynamic dependencies, like `ldd' under 34971 SunOS 4. 34972 34973 -- Macro: PARSE_LDD_OUTPUT (PTR) 34974 Define this macro to be C code that extracts filenames from the 34975 output of the program denoted by `LDD_SUFFIX'. PTR is a variable 34976 of type `char *' that points to the beginning of a line of output 34977 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the 34978 code must advance PTR to the beginning of the filename on that 34979 line. Otherwise, it must set PTR to `NULL'. 34980 34981 -- Macro: SHLIB_SUFFIX 34982 Define this macro to a C string constant containing the default 34983 shared library extension of the target (e.g., `".so"'). `collect2' 34984 strips version information after this suffix when generating global 34985 constructor and destructor names. This define is only needed on 34986 targets that use `collect2' to process constructors and 34987 destructors. 34988 34989 34990File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 34991 3499217.21.7 Output of Assembler Instructions 34993---------------------------------------- 34994 34995This describes assembler instruction output. 34996 34997 -- Macro: REGISTER_NAMES 34998 A C initializer containing the assembler's names for the machine 34999 registers, each one as a C string constant. This is what 35000 translates register numbers in the compiler into assembler 35001 language. 35002 35003 -- Macro: ADDITIONAL_REGISTER_NAMES 35004 If defined, a C initializer for an array of structures containing 35005 a name and a register number. This macro defines additional names 35006 for hard registers, thus allowing the `asm' option in declarations 35007 to refer to registers using alternate names. 35008 35009 -- Macro: OVERLAPPING_REGISTER_NAMES 35010 If defined, a C initializer for an array of structures containing a 35011 name, a register number and a count of the number of consecutive 35012 machine registers the name overlaps. This macro defines additional 35013 names for hard registers, thus allowing the `asm' option in 35014 declarations to refer to registers using alternate names. Unlike 35015 `ADDITIONAL_REGISTER_NAMES', this macro should be used when the 35016 register name implies multiple underlying registers. 35017 35018 This macro should be used when it is important that a clobber in an 35019 `asm' statement clobbers all the underlying values implied by the 35020 register name. For example, on ARM, clobbering the 35021 double-precision VFP register "d0" implies clobbering both 35022 single-precision registers "s0" and "s1". 35023 35024 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 35025 Define this macro if you are using an unusual assembler that 35026 requires different names for the machine instructions. 35027 35028 The definition is a C statement or statements which output an 35029 assembler instruction opcode to the stdio stream STREAM. The 35030 macro-operand PTR is a variable of type `char *' which points to 35031 the opcode name in its "internal" form--the form that is written 35032 in the machine description. The definition should output the 35033 opcode name to STREAM, performing any translation you desire, and 35034 increment the variable PTR to point at the end of the opcode so 35035 that it will not be output twice. 35036 35037 In fact, your macro definition may process less than the entire 35038 opcode name, or more than the opcode name; but if you want to 35039 process text that includes `%'-sequences to substitute operands, 35040 you must take care of the substitution yourself. Just be sure to 35041 increment PTR over whatever text should not be output normally. 35042 35043 If you need to look at the operand values, they can be found as the 35044 elements of `recog_data.operand'. 35045 35046 If the macro definition does nothing, the instruction is output in 35047 the usual way. 35048 35049 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 35050 If defined, a C statement to be executed just prior to the output 35051 of assembler code for INSN, to modify the extracted operands so 35052 they will be output differently. 35053 35054 Here the argument OPVEC is the vector containing the operands 35055 extracted from INSN, and NOPERANDS is the number of elements of 35056 the vector which contain meaningful data for this insn. The 35057 contents of this vector are what will be used to convert the insn 35058 template into assembler code, so you can change the assembler 35059 output by changing the contents of the vector. 35060 35061 This macro is useful when various assembler syntaxes share a single 35062 file of instruction patterns; by defining this macro differently, 35063 you can cause a large class of instructions to be output 35064 differently (such as with rearranged operands). Naturally, 35065 variations in assembler syntax affecting individual insn patterns 35066 ought to be handled by writing conditional output routines in 35067 those patterns. 35068 35069 If this macro is not defined, it is equivalent to a null statement. 35070 35071 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, rtx 35072 INSN, rtx *OPVEC, int NOPERANDS) 35073 If defined, this target hook is a function which is executed just 35074 after the output of assembler code for INSN, to change the mode of 35075 the assembler if necessary. 35076 35077 Here the argument OPVEC is the vector containing the operands 35078 extracted from INSN, and NOPERANDS is the number of elements of 35079 the vector which contain meaningful data for this insn. The 35080 contents of this vector are what was used to convert the insn 35081 template into assembler code, so you can change the assembler mode 35082 by checking the contents of the vector. 35083 35084 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 35085 A C compound statement to output to stdio stream STREAM the 35086 assembler syntax for an instruction operand X. X is an RTL 35087 expression. 35088 35089 CODE is a value that can be used to specify one of several ways of 35090 printing the operand. It is used when identical operands must be 35091 printed differently depending on the context. CODE comes from the 35092 `%' specification that was used to request printing of the 35093 operand. If the specification was just `%DIGIT' then CODE is 0; 35094 if the specification was `%LTR DIGIT' then CODE is the ASCII code 35095 for LTR. 35096 35097 If X is a register, this macro should print the register's name. 35098 The names can be found in an array `reg_names' whose type is `char 35099 *[]'. `reg_names' is initialized from `REGISTER_NAMES'. 35100 35101 When the machine description has a specification `%PUNCT' (a `%' 35102 followed by a punctuation character), this macro is called with a 35103 null pointer for X and the punctuation character for CODE. 35104 35105 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 35106 A C expression which evaluates to true if CODE is a valid 35107 punctuation character for use in the `PRINT_OPERAND' macro. If 35108 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 35109 punctuation characters (except for the standard one, `%') are used 35110 in this way. 35111 35112 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 35113 A C compound statement to output to stdio stream STREAM the 35114 assembler syntax for an instruction operand that is a memory 35115 reference whose address is X. X is an RTL expression. 35116 35117 On some machines, the syntax for a symbolic address depends on the 35118 section that the address refers to. On these machines, define the 35119 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the 35120 `symbol_ref', and then check for it here. *Note Assembler 35121 Format::. 35122 35123 -- Macro: DBR_OUTPUT_SEQEND (FILE) 35124 A C statement, to be executed after all slot-filler instructions 35125 have been output. If necessary, call `dbr_sequence_length' to 35126 determine the number of slots filled in a sequence (zero if not 35127 currently outputting a sequence), to decide how many no-ops to 35128 output, or whatever. 35129 35130 Don't define this macro if it has nothing to do, but it is helpful 35131 in reading assembly output if the extent of the delay sequence is 35132 made explicit (e.g. with white space). 35133 35134 Note that output routines for instructions with delay slots must be 35135prepared to deal with not being output as part of a sequence (i.e. when 35136the scheduling pass is not run, or when no slot fillers could be 35137found.) The variable `final_sequence' is null when not processing a 35138sequence, otherwise it contains the `sequence' rtx being output. 35139 35140 -- Macro: REGISTER_PREFIX 35141 -- Macro: LOCAL_LABEL_PREFIX 35142 -- Macro: USER_LABEL_PREFIX 35143 -- Macro: IMMEDIATE_PREFIX 35144 If defined, C string expressions to be used for the `%R', `%L', 35145 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These 35146 are useful when a single `md' file must support multiple assembler 35147 formats. In that case, the various `tm.h' files can define these 35148 macros differently. 35149 35150 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 35151 If defined this macro should expand to a series of `case' 35152 statements which will be parsed inside the `switch' statement of 35153 the `asm_fprintf' function. This allows targets to define extra 35154 printf formats which may useful when generating their assembler 35155 statements. Note that uppercase letters are reserved for future 35156 generic extensions to asm_fprintf, and so are not available to 35157 target specific code. The output file is given by the parameter 35158 FILE. The varargs input pointer is ARGPTR and the rest of the 35159 format string, starting the character after the one that is being 35160 switched upon, is pointed to by FORMAT. 35161 35162 -- Macro: ASSEMBLER_DIALECT 35163 If your target supports multiple dialects of assembler language 35164 (such as different opcodes), define this macro as a C expression 35165 that gives the numeric index of the assembler language dialect to 35166 use, with zero as the first variant. 35167 35168 If this macro is defined, you may use constructs of the form 35169 `{option0|option1|option2...}' 35170 in the output templates of patterns (*note Output Template::) or 35171 in the first argument of `asm_fprintf'. This construct outputs 35172 `option0', `option1', `option2', etc., if the value of 35173 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 35174 within these strings retain their usual meaning. If there are 35175 fewer alternatives within the braces than the value of 35176 `ASSEMBLER_DIALECT', the construct outputs nothing. 35177 35178 If you do not define this macro, the characters `{', `|' and `}' 35179 do not have any special meaning when used in templates or operands 35180 to `asm_fprintf'. 35181 35182 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', 35183 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the 35184 variations in assembler language syntax with that mechanism. 35185 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax 35186 if the syntax variant are larger and involve such things as 35187 different opcodes or operand order. 35188 35189 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 35190 A C expression to output to STREAM some assembler code which will 35191 push hard register number REGNO onto the stack. The code need not 35192 be optimal, since this macro is used only when profiling. 35193 35194 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 35195 A C expression to output to STREAM some assembler code which will 35196 pop hard register number REGNO off of the stack. The code need 35197 not be optimal, since this macro is used only when profiling. 35198 35199 35200File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 35201 3520217.21.8 Output of Dispatch Tables 35203--------------------------------- 35204 35205This concerns dispatch tables. 35206 35207 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 35208 A C statement to output to the stdio stream STREAM an assembler 35209 pseudo-instruction to generate a difference between two labels. 35210 VALUE and REL are the numbers of two internal labels. The 35211 definitions of these labels are output using 35212 `(*targetm.asm_out.internal_label)', and they must be printed in 35213 the same way here. For example, 35214 35215 fprintf (STREAM, "\t.word L%d-L%d\n", 35216 VALUE, REL) 35217 35218 You must provide this macro on machines where the addresses in a 35219 dispatch table are relative to the table's own address. If 35220 defined, GCC will also use this macro on all machines when 35221 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is 35222 provided so that the mode and flags can be read. 35223 35224 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 35225 This macro should be provided on machines where the addresses in a 35226 dispatch table are absolute. 35227 35228 The definition should be a C statement to output to the stdio 35229 stream STREAM an assembler pseudo-instruction to generate a 35230 reference to a label. VALUE is the number of an internal label 35231 whose definition is output using 35232 `(*targetm.asm_out.internal_label)'. For example, 35233 35234 fprintf (STREAM, "\t.word L%d\n", VALUE) 35235 35236 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 35237 Define this if the label before a jump-table needs to be output 35238 specially. The first three arguments are the same as for 35239 `(*targetm.asm_out.internal_label)'; the fourth argument is the 35240 jump-table which follows (a `jump_insn' containing an `addr_vec' 35241 or `addr_diff_vec'). 35242 35243 This feature is used on system V to output a `swbeg' statement for 35244 the table. 35245 35246 If this macro is not defined, these labels are output with 35247 `(*targetm.asm_out.internal_label)'. 35248 35249 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 35250 Define this if something special must be output at the end of a 35251 jump-table. The definition should be a C statement to be executed 35252 after the assembler code for the table is written. It should write 35253 the appropriate code to stdio stream STREAM. The argument TABLE 35254 is the jump-table insn, and NUM is the label-number of the 35255 preceding label. 35256 35257 If this macro is not defined, nothing special is output at the end 35258 of the jump-table. 35259 35260 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 35261 DECL, int FOR_EH, int EMPTY) 35262 This target hook emits a label at the beginning of each FDE. It 35263 should be defined on targets where FDEs need special labels, and it 35264 should write the appropriate label, for the FDE associated with the 35265 function declaration DECL, to the stdio stream STREAM. The third 35266 argument, FOR_EH, is a boolean: true if this is for an exception 35267 table. The fourth argument, EMPTY, is a boolean: true if this is 35268 a placeholder label for an omitted FDE. 35269 35270 The default is that FDEs are not given nonlocal labels. 35271 35272 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 35273 This target hook emits a label at the beginning of the exception 35274 table. It should be defined on targets where it is desirable for 35275 the table to be broken up according to function. 35276 35277 The default is that no label is emitted. 35278 35279 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 35280 PERSONALITY) 35281 If the target implements `TARGET_ASM_UNWIND_EMIT', this hook may 35282 be used to emit a directive to install a personality hook into the 35283 unwind info. This hook should not be used if dwarf2 unwind info 35284 is used. 35285 35286 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx INSN) 35287 This target hook emits assembly directives required to unwind the 35288 given instruction. This is only used when 35289 `TARGET_EXCEPT_UNWIND_INFO' returns `UI_TARGET'. 35290 35291 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 35292 True if the `TARGET_ASM_UNWIND_EMIT' hook should be called before 35293 the assembly for INSN has been emitted, false if the hook should 35294 be called afterward. 35295 35296 35297File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 35298 3529917.21.9 Assembler Commands for Exception Regions 35300------------------------------------------------ 35301 35302This describes commands marking the start and the end of an exception 35303region. 35304 35305 -- Macro: EH_FRAME_SECTION_NAME 35306 If defined, a C string constant for the name of the section 35307 containing exception handling frame unwind information. If not 35308 defined, GCC will provide a default definition if the target 35309 supports named sections. `crtstuff.c' uses this macro to switch 35310 to the appropriate section. 35311 35312 You should define this symbol if your target supports DWARF 2 frame 35313 unwind information and the default definition does not work. 35314 35315 -- Macro: EH_FRAME_IN_DATA_SECTION 35316 If defined, DWARF 2 frame unwind information will be placed in the 35317 data section even though the target supports named sections. This 35318 might be necessary, for instance, if the system linker does garbage 35319 collection and sections cannot be marked as not to be collected. 35320 35321 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also 35322 defined. 35323 35324 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 35325 Define this macro to 1 if your target is such that no frame unwind 35326 information encoding used with non-PIC code will ever require a 35327 runtime relocation, but the linker may not support merging 35328 read-only and read-write sections into a single read-write section. 35329 35330 -- Macro: MASK_RETURN_ADDR 35331 An rtx used to mask the return address found via 35332 `RETURN_ADDR_RTX', so that it does not contain any extraneous set 35333 bits in it. 35334 35335 -- Macro: DWARF2_UNWIND_INFO 35336 Define this macro to 0 if your target supports DWARF 2 frame unwind 35337 information, but it does not yet work with exception handling. 35338 Otherwise, if your target supports this information (if it defines 35339 `INCOMING_RETURN_ADDR_RTX' and `OBJECT_FORMAT_ELF'), GCC will 35340 provide a default definition of 1. 35341 35342 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 35343 (struct gcc_options *OPTS) 35344 This hook defines the mechanism that will be used for exception 35345 handling by the target. If the target has ABI specified unwind 35346 tables, the hook should return `UI_TARGET'. If the target is to 35347 use the `setjmp'/`longjmp'-based exception handling scheme, the 35348 hook should return `UI_SJLJ'. If the target supports DWARF 2 35349 frame unwind information, the hook should return `UI_DWARF2'. 35350 35351 A target may, if exceptions are disabled, choose to return 35352 `UI_NONE'. This may end up simplifying other parts of 35353 target-specific code. The default implementation of this hook 35354 never returns `UI_NONE'. 35355 35356 Note that the value returned by this hook should be constant. It 35357 should not depend on anything except the command-line switches 35358 described by OPTS. In particular, the setting `UI_SJLJ' must be 35359 fixed at compiler start-up as C pre-processor macros and builtin 35360 functions related to exception handling are set up depending on 35361 this setting. 35362 35363 The default implementation of the hook first honors the 35364 `--enable-sjlj-exceptions' configure option, then 35365 `DWARF2_UNWIND_INFO', and finally defaults to `UI_SJLJ'. If 35366 `DWARF2_UNWIND_INFO' depends on command-line options, the target 35367 must define this hook so that OPTS is used correctly. 35368 35369 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 35370 This variable should be set to `true' if the target ABI requires 35371 unwinding tables even when exceptions are not used. It must not 35372 be modified by command-line option processing. 35373 35374 -- Macro: DONT_USE_BUILTIN_SETJMP 35375 Define this macro to 1 if the `setjmp'/`longjmp'-based scheme 35376 should use the `setjmp'/`longjmp' functions from the C library 35377 instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery. 35378 35379 -- Macro: JMP_BUF_SIZE 35380 This macro has no effect unless `DONT_USE_BUILTIN_SETJMP' is also 35381 defined. Define this macro if the default size of `jmp_buf' buffer 35382 for the `setjmp'/`longjmp'-based exception handling mechanism is 35383 not large enough, or if it is much too large. The default size is 35384 `FIRST_PSEUDO_REGISTER * sizeof(void *)'. 35385 35386 -- Macro: DWARF_CIE_DATA_ALIGNMENT 35387 This macro need only be defined if the target might save registers 35388 in the function prologue at an offset to the stack pointer that is 35389 not aligned to `UNITS_PER_WORD'. The definition should be the 35390 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined, 35391 and the positive minimum alignment otherwise. *Note SDB and 35392 DWARF::. Only applicable if the target supports DWARF 2 frame 35393 unwind information. 35394 35395 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 35396 Contains the value true if the target should add a zero word onto 35397 the end of a Dwarf-2 frame info section when used for exception 35398 handling. Default value is false if `EH_FRAME_SECTION_NAME' is 35399 defined, and true otherwise. 35400 35401 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 35402 Given a register, this hook should return a parallel of registers 35403 to represent where to find the register pieces. Define this hook 35404 if the register and its mode are represented in Dwarf in 35405 non-contiguous locations, or if the register should be represented 35406 in more than one register in Dwarf. Otherwise, this hook should 35407 return `NULL_RTX'. If not defined, the default is to return 35408 `NULL_RTX'. 35409 35410 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 35411 If some registers are represented in Dwarf-2 unwind information in 35412 multiple pieces, define this hook to fill in information about the 35413 sizes of those pieces in the table used by the unwinder at runtime. 35414 It will be called by `expand_builtin_init_dwarf_reg_sizes' after 35415 filling in a single size corresponding to each hard register; 35416 ADDRESS is the address of the table. 35417 35418 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 35419 This hook is used to output a reference from a frame unwinding 35420 table to the type_info object identified by SYM. It should return 35421 `true' if the reference was output. Returning `false' will cause 35422 the reference to be output using the normal Dwarf2 routines. 35423 35424 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 35425 This flag should be set to `true' on targets that use an ARM EABI 35426 based unwinding library, and `false' on other targets. This 35427 effects the format of unwinding tables, and how the unwinder in 35428 entered after running a cleanup. The default is `false'. 35429 35430 35431File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 35432 3543317.21.10 Assembler Commands for Alignment 35434----------------------------------------- 35435 35436This describes commands for alignment. 35437 35438 -- Macro: JUMP_ALIGN (LABEL) 35439 The alignment (log base 2) to put in front of LABEL, which is a 35440 common destination of jumps and has no fallthru incoming edge. 35441 35442 This macro need not be defined if you don't want any special 35443 alignment to be done at such a time. Most machine descriptions do 35444 not currently define the macro. 35445 35446 Unless it's necessary to inspect the LABEL parameter, it is better 35447 to set the variable ALIGN_JUMPS in the target's 35448 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 35449 user's selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation. 35450 35451 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx LABEL) 35452 The maximum number of bytes to skip before LABEL when applying 35453 `JUMP_ALIGN'. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is 35454 defined. 35455 35456 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 35457 The alignment (log base 2) to put in front of LABEL, which follows 35458 a `BARRIER'. 35459 35460 This macro need not be defined if you don't want any special 35461 alignment to be done at such a time. Most machine descriptions do 35462 not currently define the macro. 35463 35464 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP (rtx 35465 LABEL) 35466 The maximum number of bytes to skip before LABEL when applying 35467 `LABEL_ALIGN_AFTER_BARRIER'. This works only if 35468 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 35469 35470 -- Macro: LOOP_ALIGN (LABEL) 35471 The alignment (log base 2) to put in front of LABEL, which follows 35472 a `NOTE_INSN_LOOP_BEG' note. 35473 35474 This macro need not be defined if you don't want any special 35475 alignment to be done at such a time. Most machine descriptions do 35476 not currently define the macro. 35477 35478 Unless it's necessary to inspect the LABEL parameter, it is better 35479 to set the variable `align_loops' in the target's 35480 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 35481 user's selection in `align_loops' in a `LOOP_ALIGN' implementation. 35482 35483 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx LABEL) 35484 The maximum number of bytes to skip when applying `LOOP_ALIGN' to 35485 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 35486 35487 -- Macro: LABEL_ALIGN (LABEL) 35488 The alignment (log base 2) to put in front of LABEL. If 35489 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different 35490 alignment, the maximum of the specified values is used. 35491 35492 Unless it's necessary to inspect the LABEL parameter, it is better 35493 to set the variable `align_labels' in the target's 35494 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 35495 user's selection in `align_labels' in a `LABEL_ALIGN' 35496 implementation. 35497 35498 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx LABEL) 35499 The maximum number of bytes to skip when applying `LABEL_ALIGN' to 35500 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 35501 35502 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 35503 A C statement to output to the stdio stream STREAM an assembler 35504 instruction to advance the location counter by NBYTES bytes. 35505 Those bytes should be zero when loaded. NBYTES will be a C 35506 expression of type `unsigned HOST_WIDE_INT'. 35507 35508 -- Macro: ASM_NO_SKIP_IN_TEXT 35509 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the 35510 text section because it fails to put zeros in the bytes that are 35511 skipped. This is true on many Unix systems, where the pseudo-op 35512 to skip bytes produces no-op instructions rather than zeros when 35513 used in the text section. 35514 35515 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 35516 A C statement to output to the stdio stream STREAM an assembler 35517 command to advance the location counter to a multiple of 2 to the 35518 POWER bytes. POWER will be a C expression of type `int'. 35519 35520 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 35521 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 35522 for padding, if necessary. 35523 35524 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 35525 A C statement to output to the stdio stream STREAM an assembler 35526 command to advance the location counter to a multiple of 2 to the 35527 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 35528 satisfy the alignment request. POWER and MAX_SKIP will be a C 35529 expression of type `int'. 35530 35531 35532File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 35533 3553417.22 Controlling Debugging Information Format 35535============================================== 35536 35537This describes how to specify debugging information. 35538 35539* Menu: 35540 35541* All Debuggers:: Macros that affect all debugging formats uniformly. 35542* DBX Options:: Macros enabling specific options in DBX format. 35543* DBX Hooks:: Hook macros for varying DBX format. 35544* File Names and DBX:: Macros controlling output of file names in DBX format. 35545* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 35546* VMS Debug:: Macros for VMS debug format. 35547 35548 35549File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 35550 3555117.22.1 Macros Affecting All Debugging Formats 35552---------------------------------------------- 35553 35554These macros affect all debugging formats. 35555 35556 -- Macro: DBX_REGISTER_NUMBER (REGNO) 35557 A C expression that returns the DBX register number for the 35558 compiler register number REGNO. In the default macro provided, 35559 the value of this expression will be REGNO itself. But sometimes 35560 there are some registers that the compiler knows about and DBX 35561 does not, or vice versa. In such cases, some register may need to 35562 have one number in the compiler and another for DBX. 35563 35564 If two registers have consecutive numbers inside GCC, and they can 35565 be used as a pair to hold a multiword value, then they _must_ have 35566 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'. 35567 Otherwise, debuggers will be unable to access such a pair, because 35568 they expect register pairs to be consecutive in their own 35569 numbering scheme. 35570 35571 If you find yourself defining `DBX_REGISTER_NUMBER' in way that 35572 does not preserve register pairs, then what you must do instead is 35573 redefine the actual register numbering scheme. 35574 35575 -- Macro: DEBUGGER_AUTO_OFFSET (X) 35576 A C expression that returns the integer offset value for an 35577 automatic variable having address X (an RTL expression). The 35578 default computation assumes that X is based on the frame-pointer 35579 and gives the offset from the frame-pointer. This is required for 35580 targets that produce debugging output for DBX or COFF-style 35581 debugging output for SDB and allow the frame-pointer to be 35582 eliminated when the `-g' options is used. 35583 35584 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 35585 A C expression that returns the integer offset value for an 35586 argument having address X (an RTL expression). The nominal offset 35587 is OFFSET. 35588 35589 -- Macro: PREFERRED_DEBUGGING_TYPE 35590 A C expression that returns the type of debugging output GCC should 35591 produce when the user specifies just `-g'. Define this if you 35592 have arranged for GCC to support more than one format of debugging 35593 output. Currently, the allowable values are `DBX_DEBUG', 35594 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG', 35595 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'. 35596 35597 When the user specifies `-ggdb', GCC normally also uses the value 35598 of this macro to select the debugging output format, but with two 35599 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the 35600 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is 35601 defined, GCC uses `DBX_DEBUG'. 35602 35603 The value of this macro only affects the default debugging output; 35604 the user can always get a specific type of output by using 35605 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'. 35606 35607 35608File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 35609 3561017.22.2 Specific Options for DBX Output 35611--------------------------------------- 35612 35613These are specific options for DBX output. 35614 35615 -- Macro: DBX_DEBUGGING_INFO 35616 Define this macro if GCC should produce debugging output for DBX 35617 in response to the `-g' option. 35618 35619 -- Macro: XCOFF_DEBUGGING_INFO 35620 Define this macro if GCC should produce XCOFF format debugging 35621 output in response to the `-g' option. This is a variant of DBX 35622 format. 35623 35624 -- Macro: DEFAULT_GDB_EXTENSIONS 35625 Define this macro to control whether GCC should by default generate 35626 GDB's extended version of DBX debugging information (assuming 35627 DBX-format debugging information is enabled at all). If you don't 35628 define the macro, the default is 1: always generate the extended 35629 information if there is any occasion to. 35630 35631 -- Macro: DEBUG_SYMS_TEXT 35632 Define this macro if all `.stabs' commands should be output while 35633 in the text section. 35634 35635 -- Macro: ASM_STABS_OP 35636 A C string constant, including spacing, naming the assembler 35637 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary 35638 debugging symbol. If you don't define this macro, `"\t.stabs\t"' 35639 is used. This macro applies only to DBX debugging information 35640 format. 35641 35642 -- Macro: ASM_STABD_OP 35643 A C string constant, including spacing, naming the assembler 35644 pseudo op to use instead of `"\t.stabd\t"' to define a debugging 35645 symbol whose value is the current location. If you don't define 35646 this macro, `"\t.stabd\t"' is used. This macro applies only to 35647 DBX debugging information format. 35648 35649 -- Macro: ASM_STABN_OP 35650 A C string constant, including spacing, naming the assembler 35651 pseudo op to use instead of `"\t.stabn\t"' to define a debugging 35652 symbol with no name. If you don't define this macro, 35653 `"\t.stabn\t"' is used. This macro applies only to DBX debugging 35654 information format. 35655 35656 -- Macro: DBX_NO_XREFS 35657 Define this macro if DBX on your system does not support the 35658 construct `xsTAGNAME'. On some systems, this construct is used to 35659 describe a forward reference to a structure named TAGNAME. On 35660 other systems, this construct is not supported at all. 35661 35662 -- Macro: DBX_CONTIN_LENGTH 35663 A symbol name in DBX-format debugging information is normally 35664 continued (split into two separate `.stabs' directives) when it 35665 exceeds a certain length (by default, 80 characters). On some 35666 operating systems, DBX requires this splitting; on others, 35667 splitting must not be done. You can inhibit splitting by defining 35668 this macro with the value zero. You can override the default 35669 splitting-length by defining this macro as an expression for the 35670 length you desire. 35671 35672 -- Macro: DBX_CONTIN_CHAR 35673 Normally continuation is indicated by adding a `\' character to 35674 the end of a `.stabs' string when a continuation follows. To use 35675 a different character instead, define this macro as a character 35676 constant for the character you want to use. Do not define this 35677 macro if backslash is correct for your system. 35678 35679 -- Macro: DBX_STATIC_STAB_DATA_SECTION 35680 Define this macro if it is necessary to go to the data section 35681 before outputting the `.stabs' pseudo-op for a non-global static 35682 variable. 35683 35684 -- Macro: DBX_TYPE_DECL_STABS_CODE 35685 The value to use in the "code" field of the `.stabs' directive for 35686 a typedef. The default is `N_LSYM'. 35687 35688 -- Macro: DBX_STATIC_CONST_VAR_CODE 35689 The value to use in the "code" field of the `.stabs' directive for 35690 a static variable located in the text section. DBX format does not 35691 provide any "right" way to do this. The default is `N_FUN'. 35692 35693 -- Macro: DBX_REGPARM_STABS_CODE 35694 The value to use in the "code" field of the `.stabs' directive for 35695 a parameter passed in registers. DBX format does not provide any 35696 "right" way to do this. The default is `N_RSYM'. 35697 35698 -- Macro: DBX_REGPARM_STABS_LETTER 35699 The letter to use in DBX symbol data to identify a symbol as a 35700 parameter passed in registers. DBX format does not customarily 35701 provide any way to do this. The default is `'P''. 35702 35703 -- Macro: DBX_FUNCTION_FIRST 35704 Define this macro if the DBX information for a function and its 35705 arguments should precede the assembler code for the function. 35706 Normally, in DBX format, the debugging information entirely 35707 follows the assembler code. 35708 35709 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 35710 Define this macro, with value 1, if the value of a symbol 35711 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be 35712 relative to the start of the enclosing function. Normally, GCC 35713 uses an absolute address. 35714 35715 -- Macro: DBX_LINES_FUNCTION_RELATIVE 35716 Define this macro, with value 1, if the value of a symbol 35717 indicating the current line number (`N_SLINE') should be relative 35718 to the start of the enclosing function. Normally, GCC uses an 35719 absolute address. 35720 35721 -- Macro: DBX_USE_BINCL 35722 Define this macro if GCC should generate `N_BINCL' and `N_EINCL' 35723 stabs for included header files, as on Sun systems. This macro 35724 also directs GCC to output a type number as a pair of a file 35725 number and a type number within the file. Normally, GCC does not 35726 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single 35727 number for a type number. 35728 35729 35730File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 35731 3573217.22.3 Open-Ended Hooks for DBX Format 35733--------------------------------------- 35734 35735These are hooks for DBX format. 35736 35737 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 35738 A C statement to output DBX debugging information before code for 35739 line number LINE of the current source file to the stdio stream 35740 STREAM. COUNTER is the number of time the macro was invoked, 35741 including the current invocation; it is intended to generate 35742 unique labels in the assembly output. 35743 35744 This macro should not be defined if the default output is correct, 35745 or if it can be made correct by defining 35746 `DBX_LINES_FUNCTION_RELATIVE'. 35747 35748 -- Macro: NO_DBX_FUNCTION_END 35749 Some stabs encapsulation formats (in particular ECOFF), cannot 35750 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 35751 extension construct. On those machines, define this macro to turn 35752 this feature off without disturbing the rest of the gdb extensions. 35753 35754 -- Macro: NO_DBX_BNSYM_ENSYM 35755 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx 35756 extension construct. On those machines, define this macro to turn 35757 this feature off without disturbing the rest of the gdb extensions. 35758 35759 35760File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 35761 3576217.22.4 File Names in DBX Format 35763-------------------------------- 35764 35765This describes file names in DBX format. 35766 35767 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 35768 A C statement to output DBX debugging information to the stdio 35769 stream STREAM, which indicates that file NAME is the main source 35770 file--the file specified as the input file for compilation. This 35771 macro is called only once, at the beginning of compilation. 35772 35773 This macro need not be defined if the standard form of output for 35774 DBX debugging information is appropriate. 35775 35776 It may be necessary to refer to a label equal to the beginning of 35777 the text section. You can use `assemble_name (stream, 35778 ltext_label_name)' to do so. If you do this, you must also set 35779 the variable USED_LTEXT_LABEL_NAME to `true'. 35780 35781 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 35782 Define this macro, with value 1, if GCC should not emit an 35783 indication of the current directory for compilation and current 35784 source language at the beginning of the file. 35785 35786 -- Macro: NO_DBX_GCC_MARKER 35787 Define this macro, with value 1, if GCC should not emit an 35788 indication that this object file was compiled by GCC. The default 35789 is to emit an `N_OPT' stab at the beginning of every source file, 35790 with `gcc2_compiled.' for the string and value 0. 35791 35792 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 35793 A C statement to output DBX debugging information at the end of 35794 compilation of the main source file NAME. Output should be 35795 written to the stdio stream STREAM. 35796 35797 If you don't define this macro, nothing special is output at the 35798 end of compilation, which is correct for most machines. 35799 35800 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 35801 Define this macro _instead of_ defining 35802 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 35803 the end of compilation is an `N_SO' stab with an empty string, 35804 whose value is the highest absolute text address in the file. 35805 35806 35807File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 35808 3580917.22.5 Macros for SDB and DWARF Output 35810--------------------------------------- 35811 35812Here are macros for SDB and DWARF output. 35813 35814 -- Macro: SDB_DEBUGGING_INFO 35815 Define this macro if GCC should produce COFF-style debugging output 35816 for SDB in response to the `-g' option. 35817 35818 -- Macro: DWARF2_DEBUGGING_INFO 35819 Define this macro if GCC should produce dwarf version 2 format 35820 debugging output in response to the `-g' option. 35821 35822 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 35823 FUNCTION) 35824 Define this to enable the dwarf attribute 35825 `DW_AT_calling_convention' to be emitted for each function. 35826 Instead of an integer return the enum value for the `DW_CC_' 35827 tag. 35828 35829 To support optional call frame debugging information, you must also 35830 define `INCOMING_RETURN_ADDR_RTX' and either set 35831 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 35832 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as 35833 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 35834 35835 -- Macro: DWARF2_FRAME_INFO 35836 Define this macro to a nonzero value if GCC should always output 35837 Dwarf 2 frame information. If `TARGET_EXCEPT_UNWIND_INFO' (*note 35838 Exception Region Output::) returns `UI_DWARF2', and exceptions are 35839 enabled, GCC will output this information not matter how you 35840 define `DWARF2_FRAME_INFO'. 35841 35842 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 35843 This hook defines the mechanism that will be used for describing 35844 frame unwind information to the debugger. Normally the hook will 35845 return `UI_DWARF2' if DWARF 2 debug information is enabled, and 35846 return `UI_NONE' otherwise. 35847 35848 A target may return `UI_DWARF2' even when DWARF 2 debug information 35849 is disabled in order to always output DWARF 2 frame information. 35850 35851 A target may return `UI_TARGET' if it has ABI specified unwind 35852 tables. This will suppress generation of the normal debug frame 35853 unwind information. 35854 35855 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 35856 Define this macro to be a nonzero value if the assembler can 35857 generate Dwarf 2 line debug info sections. This will result in 35858 much more compact line number tables, and hence is desirable if it 35859 works. 35860 35861 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 35862 True if the `.debug_pubtypes' and `.debug_pubnames' sections 35863 should be emitted. These sections are not used on most platforms, 35864 and in particular GDB does not use them. 35865 35866 -- Target Hook: bool TARGET_FORCE_AT_COMP_DIR 35867 True if the `DW_AT_comp_dir' attribute should be emitted for each 35868 compilation unit. This attribute is required for the darwin 35869 linker to emit debug information. 35870 35871 -- Target Hook: bool TARGET_DELAY_SCHED2 35872 True if sched2 is not to be run at its normal place. This usually 35873 means it will be run as part of machine-specific reorg. 35874 35875 -- Target Hook: bool TARGET_DELAY_VARTRACK 35876 True if vartrack is not to be run at its normal place. This 35877 usually means it will be run as part of machine-specific reorg. 35878 35879 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 35880 A C statement to issue assembly directives that create a difference 35881 LAB1 minus LAB2, using an integer of the given SIZE. 35882 35883 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 35884 A C statement to issue assembly directives that create a difference 35885 between the two given labels in system defined units, e.g. 35886 instruction slots on IA64 VMS, using an integer of the given size. 35887 35888 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 35889 A C statement to issue assembly directives that create a 35890 section-relative reference to the given LABEL, using an integer of 35891 the given SIZE. The label is known to be defined in the given 35892 SECTION. 35893 35894 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 35895 A C statement to issue assembly directives that create a 35896 self-relative reference to the given LABEL, using an integer of 35897 the given SIZE. 35898 35899 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 35900 A C statement to issue assembly directives that create a reference 35901 to the DWARF table identifier LABEL from the current section. This 35902 is used on some systems to avoid garbage collecting a DWARF table 35903 which is referenced by a function. 35904 35905 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 35906 SIZE, rtx X) 35907 If defined, this target hook is a function which outputs a 35908 DTP-relative reference to the given TLS symbol of the specified 35909 size. 35910 35911 -- Macro: PUT_SDB_... 35912 Define these macros to override the assembler syntax for the 35913 special SDB assembler directives. See `sdbout.c' for a list of 35914 these macros and their arguments. If the standard syntax is used, 35915 you need not define them yourself. 35916 35917 -- Macro: SDB_DELIM 35918 Some assemblers do not support a semicolon as a delimiter, even 35919 between SDB assembler directives. In that case, define this macro 35920 to be the delimiter to use (usually `\n'). It is not necessary to 35921 define a new set of `PUT_SDB_OP' macros if this is the only change 35922 required. 35923 35924 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 35925 Define this macro to allow references to unknown structure, union, 35926 or enumeration tags to be emitted. Standard COFF does not allow 35927 handling of unknown references, MIPS ECOFF has support for it. 35928 35929 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 35930 Define this macro to allow references to structure, union, or 35931 enumeration tags that have not yet been seen to be handled. Some 35932 assemblers choke if forward tags are used, while some require it. 35933 35934 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 35935 A C statement to output SDB debugging information before code for 35936 line number LINE of the current source file to the stdio stream 35937 STREAM. The default is to emit an `.ln' directive. 35938 35939 35940File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 35941 3594217.22.6 Macros for VMS Debug Format 35943----------------------------------- 35944 35945Here are macros for VMS debug format. 35946 35947 -- Macro: VMS_DEBUGGING_INFO 35948 Define this macro if GCC should produce debugging output for VMS 35949 in response to the `-g' option. The default behavior for VMS is 35950 to generate minimal debug info for a traceback in the absence of 35951 `-g' unless explicitly overridden with `-g0'. This behavior is 35952 controlled by `TARGET_OPTION_OPTIMIZATION' and 35953 `TARGET_OPTION_OVERRIDE'. 35954 35955 35956File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 35957 3595817.23 Cross Compilation and Floating Point 35959========================================== 35960 35961While all modern machines use twos-complement representation for 35962integers, there are a variety of representations for floating point 35963numbers. This means that in a cross-compiler the representation of 35964floating point numbers in the compiled program may be different from 35965that used in the machine doing the compilation. 35966 35967 Because different representation systems may offer different amounts of 35968range and precision, all floating point constants must be represented in 35969the target machine's format. Therefore, the cross compiler cannot 35970safely use the host machine's floating point arithmetic; it must emulate 35971the target's arithmetic. To ensure consistency, GCC always uses 35972emulation to work with floating point values, even when the host and 35973target floating point formats are identical. 35974 35975 The following macros are provided by `real.h' for the compiler to use. 35976All parts of the compiler which generate or optimize floating-point 35977calculations must use these macros. They may evaluate their operands 35978more than once, so operands must not have side effects. 35979 35980 -- Macro: REAL_VALUE_TYPE 35981 The C data type to be used to hold a floating point value in the 35982 target machine's format. Typically this is a `struct' containing 35983 an array of `HOST_WIDE_INT', but all code should treat it as an 35984 opaque quantity. 35985 35986 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 35987 Compares for equality the two values, X and Y. If the target 35988 floating point format supports negative zeroes and/or NaNs, 35989 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL 35990 (NaN, NaN)' is false. 35991 35992 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 35993 Tests whether X is less than Y. 35994 35995 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 35996 Truncates X to a signed integer, rounding toward zero. 35997 35998 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 35999 (REAL_VALUE_TYPE X) 36000 Truncates X to an unsigned integer, rounding toward zero. If X is 36001 negative, returns zero. 36002 36003 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum 36004 machine_mode MODE) 36005 Converts STRING into a floating point number in the target 36006 machine's representation for mode MODE. This routine can handle 36007 both decimal and hexadecimal floating point constants, using the 36008 syntax defined by the C language for both. 36009 36010 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 36011 Returns 1 if X is negative (including negative zero), 0 otherwise. 36012 36013 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 36014 Determines whether X represents infinity (positive or negative). 36015 36016 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 36017 Determines whether X represents a "NaN" (not-a-number). 36018 36019 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 36020 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 36021 Calculates an arithmetic operation on the two floating point values 36022 X and Y, storing the result in OUTPUT (which must be a variable). 36023 36024 The operation to be performed is specified by CODE. Only the 36025 following codes are supported: `PLUS_EXPR', `MINUS_EXPR', 36026 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. 36027 36028 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the 36029 target's floating point format cannot represent infinity, it will 36030 call `abort'. Callers should check for this situation first, using 36031 `MODE_HAS_INFINITIES'. *Note Storage Layout::. 36032 36033 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 36034 Returns the negative of the floating point value X. 36035 36036 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 36037 Returns the absolute value of X. 36038 36039 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT 36040 HIGH, REAL_VALUE_TYPE X) 36041 Converts a floating point value X into a double-precision integer 36042 which is then stored into LOW and HIGH. If the value is not 36043 integral, it is truncated. 36044 36045 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT 36046 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE) 36047 Converts a double-precision integer found in LOW and HIGH, into a 36048 floating point value which is then stored into X. The value is 36049 truncated to fit in mode MODE. 36050 36051 36052File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 36053 3605417.24 Mode Switching Instructions 36055================================= 36056 36057The following macros control mode switching optimizations: 36058 36059 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 36060 Define this macro if the port needs extra instructions inserted 36061 for mode switching in an optimizing compilation. 36062 36063 For an example, the SH4 can perform both single and double 36064 precision floating point operations, but to perform a single 36065 precision operation, the FPSCR PR bit has to be cleared, while for 36066 a double precision operation, this bit has to be set. Changing 36067 the PR bit requires a general purpose register as a scratch 36068 register, hence these FPSCR sets have to be inserted before 36069 reload, i.e. you can't put this into instruction emitting or 36070 `TARGET_MACHINE_DEPENDENT_REORG'. 36071 36072 You can have multiple entities that are mode-switched, and select 36073 at run time which entities actually need it. 36074 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY 36075 that needs mode-switching. If you define this macro, you also 36076 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', 36077 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER', 36078 `MODE_ENTRY', and `MODE_EXIT' are optional. 36079 36080 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 36081 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as 36082 initializer for an array of integers. Each initializer element N 36083 refers to an entity that needs mode switching, and specifies the 36084 number of different modes that might need to be set for this 36085 entity. The position of the initializer in the 36086 initializer--starting counting at zero--determines the integer 36087 that is used to refer to the mode-switched entity in question. In 36088 macros that take mode arguments / yield a mode result, modes are 36089 represented as numbers 0 ... N - 1. N is used to specify that no 36090 mode switch is needed / supplied. 36091 36092 -- Macro: MODE_NEEDED (ENTITY, INSN) 36093 ENTITY is an integer specifying a mode-switched entity. If 36094 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 36095 return an integer value not larger than the corresponding element 36096 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 36097 must be switched into prior to the execution of INSN. 36098 36099 -- Macro: MODE_AFTER (ENTITY, MODE, INSN) 36100 ENTITY is an integer specifying a mode-switched entity. If this 36101 macro is defined, it is evaluated for every INSN during mode 36102 switching. It determines the mode that an insn results in (if 36103 different from the incoming mode). 36104 36105 -- Macro: MODE_ENTRY (ENTITY) 36106 If this macro is defined, it is evaluated for every ENTITY that 36107 needs mode switching. It should evaluate to an integer, which is 36108 a mode that ENTITY is assumed to be switched to at function entry. 36109 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined. 36110 36111 -- Macro: MODE_EXIT (ENTITY) 36112 If this macro is defined, it is evaluated for every ENTITY that 36113 needs mode switching. It should evaluate to an integer, which is 36114 a mode that ENTITY is assumed to be switched to at function exit. 36115 If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined. 36116 36117 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N) 36118 This macro specifies the order in which modes for ENTITY are 36119 processed. 0 is the highest priority, 36120 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 36121 of the macro should be an integer designating a mode for ENTITY. 36122 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be 36123 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'. 36124 36125 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE) 36126 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE 36127 is the set of hard registers live at the point where the insn(s) 36128 are to be inserted. 36129 36130 36131File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 36132 3613317.25 Defining target-specific uses of `__attribute__' 36134====================================================== 36135 36136Target-specific attributes may be defined for functions, data and types. 36137These are described using the following target hooks; they also need to 36138be documented in `extend.texi'. 36139 36140 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 36141 If defined, this target hook points to an array of `struct 36142 attribute_spec' (defined in `tree.h') specifying the machine 36143 specific attributes for this target and some of the restrictions 36144 on the entities to which these attributes are applied and the 36145 arguments they take. 36146 36147 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 36148 NAME) 36149 If defined, this target hook is a function which returns true if 36150 the machine-specific attribute named NAME expects an identifier 36151 given as its first argument to be passed on as a plain identifier, 36152 not subjected to name lookup. If this is not defined, the default 36153 is false for all machine-specific attributes. 36154 36155 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 36156 const_tree TYPE2) 36157 If defined, this target hook is a function which returns zero if 36158 the attributes on TYPE1 and TYPE2 are incompatible, one if they 36159 are compatible, and two if they are nearly compatible (which 36160 causes a warning to be generated). If this is not defined, 36161 machine-specific attributes are supposed always to be compatible. 36162 36163 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 36164 If defined, this target hook is a function which assigns default 36165 attributes to the newly defined TYPE. 36166 36167 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 36168 TYPE2) 36169 Define this target hook if the merging of type attributes needs 36170 special handling. If defined, the result is a list of the combined 36171 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 36172 `comptypes' has already been called and returned 1. This function 36173 may call `merge_attributes' to handle machine-independent merging. 36174 36175 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 36176 NEWDECL) 36177 Define this target hook if the merging of decl attributes needs 36178 special handling. If defined, the result is a list of the combined 36179 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 36180 declaration of OLDDECL. Examples of when this is needed are when 36181 one attribute overrides another, or when an attribute is nullified 36182 by a subsequent definition. This function may call 36183 `merge_attributes' to handle machine-independent merging. 36184 36185 If the only target-specific handling you require is `dllimport' 36186 for Microsoft Windows targets, you should define the macro 36187 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then 36188 define a function called `merge_dllimport_decl_attributes' which 36189 can then be defined as the expansion of 36190 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 36191 `handle_dll_attribute' in the attribute table for your port to 36192 perform initial processing of the `dllimport' and `dllexport' 36193 attributes. This is done in `i386/cygwin.h' and `i386/i386.c', 36194 for example. 36195 36196 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 36197 DECL) 36198 DECL is a variable or function with `__attribute__((dllimport))' 36199 specified. Use this hook if the target needs to add extra 36200 validation checks to `handle_dll_attribute'. 36201 36202 -- Macro: TARGET_DECLSPEC 36203 Define this macro to a nonzero value if you want to treat 36204 `__declspec(X)' as equivalent to `__attribute((X))'. By default, 36205 this behavior is enabled only for targets that define 36206 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 36207 `__declspec' is via a built-in macro, but you should not rely on 36208 this implementation detail. 36209 36210 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 36211 *ATTR_PTR) 36212 Define this target hook if you want to be able to add attributes 36213 to a decl when it is being created. This is normally useful for 36214 back ends which wish to implement a pragma by using the attributes 36215 which correspond to the pragma's effect. The NODE argument is the 36216 decl which is being created. The ATTR_PTR argument is a pointer 36217 to the attribute list for this decl. The list itself should not 36218 be modified, since it may be shared with other decls, but 36219 attributes may be chained on the head of the list and `*ATTR_PTR' 36220 modified to point to the new attributes, or a copy of the list may 36221 be made if further changes are needed. 36222 36223 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 36224 FNDECL) 36225 This target hook returns `true' if it is ok to inline FNDECL into 36226 the current function, despite its having target-specific 36227 attributes, `false' otherwise. By default, if a function has a 36228 target specific attribute attached to it, it will not be inlined. 36229 36230 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, 36231 tree NAME, tree ARGS, int FLAGS) 36232 This hook is called to parse `attribute(target("..."))', which 36233 allows setting target-specific options on individual functions. 36234 These function-specific options may differ from the options 36235 specified on the command line. The hook should return `true' if 36236 the options are valid. 36237 36238 The hook should set the `DECL_FUNCTION_SPECIFIC_TARGET' field in 36239 the function declaration to hold a pointer to a target-specific 36240 `struct cl_target_option' structure. 36241 36242 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR) 36243 This hook is called to save any additional target-specific 36244 information in the `struct cl_target_option' structure for 36245 function-specific options. *Note Option file format::. 36246 36247 -- Target Hook: void TARGET_OPTION_RESTORE (struct cl_target_option 36248 *PTR) 36249 This hook is called to restore any additional target-specific 36250 information in the `struct cl_target_option' structure for 36251 function-specific options. 36252 36253 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 36254 struct cl_target_option *PTR) 36255 This hook is called to print any additional target-specific 36256 information in the `struct cl_target_option' structure for 36257 function-specific options. 36258 36259 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 36260 POP_TARGET) 36261 This target hook parses the options for `#pragma GCC target', which 36262 sets the target-specific options for functions that occur later in 36263 the input stream. The options accepted should be the same as 36264 those handled by the `TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 36265 36266 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 36267 Sometimes certain combinations of command options do not make 36268 sense on a particular target machine. You can override the hook 36269 `TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 36270 called once just after all the command options have been parsed. 36271 36272 Don't use this hook to turn on various extra optimizations for 36273 `-O'. That is what `TARGET_OPTION_OPTIMIZATION' is for. 36274 36275 If you need to do something whenever the optimization level is 36276 changed via the optimize attribute or pragma, see 36277 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 36278 36279 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 36280 DECL2) 36281 This target hook returns `true' if DECL1 and DECL2 are versions of 36282 the same function. DECL1 and DECL2 are function versions if and 36283 only if they have the same function signature and different target 36284 specific attributes, that is, they are compiled for different 36285 target machines. 36286 36287 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 36288 This target hook returns `false' if the CALLER function cannot 36289 inline CALLEE, based on target specific information. By default, 36290 inlining is not allowed if the callee function has function 36291 specific target options and the caller does not use the same 36292 options. 36293 36294 36295File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 36296 3629717.26 Emulating TLS 36298=================== 36299 36300For targets whose psABI does not provide Thread Local Storage via 36301specific relocations and instruction sequences, an emulation layer is 36302used. A set of target hooks allows this emulation layer to be 36303configured for the requirements of a particular target. For instance 36304the psABI may in fact specify TLS support in terms of an emulation 36305layer. 36306 36307 The emulation layer works by creating a control object for every TLS 36308object. To access the TLS object, a lookup function is provided which, 36309when given the address of the control object, will return the address 36310of the current thread's instance of the TLS object. 36311 36312 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 36313 Contains the name of the helper function that uses a TLS control 36314 object to locate a TLS instance. The default causes libgcc's 36315 emulated TLS helper function to be used. 36316 36317 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 36318 Contains the name of the helper function that should be used at 36319 program startup to register TLS objects that are implicitly 36320 initialized to zero. If this is `NULL', all TLS objects will have 36321 explicit initializers. The default causes libgcc's emulated TLS 36322 registration function to be used. 36323 36324 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 36325 Contains the name of the section in which TLS control variables 36326 should be placed. The default of `NULL' allows these to be placed 36327 in any section. 36328 36329 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 36330 Contains the name of the section in which TLS initializers should 36331 be placed. The default of `NULL' allows these to be placed in any 36332 section. 36333 36334 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 36335 Contains the prefix to be prepended to TLS control variable names. 36336 The default of `NULL' uses a target-specific prefix. 36337 36338 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 36339 Contains the prefix to be prepended to TLS initializer objects. 36340 The default of `NULL' uses a target-specific prefix. 36341 36342 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 36343 Specifies a function that generates the FIELD_DECLs for a TLS 36344 control object type. TYPE is the RECORD_TYPE the fields are for 36345 and NAME should be filled with the structure tag, if the default of 36346 `__emutls_object' is unsuitable. The default creates a type 36347 suitable for libgcc's emulated TLS function. 36348 36349 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 36350 TMPL_ADDR) 36351 Specifies a function that generates the CONSTRUCTOR to initialize a 36352 TLS control object. VAR is the TLS control object, DECL is the 36353 TLS object and TMPL_ADDR is the address of the initializer. The 36354 default initializes libgcc's emulated TLS control object. 36355 36356 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 36357 Specifies whether the alignment of TLS control variable objects is 36358 fixed and should not be increased as some backends may do to 36359 optimize single objects. The default is false. 36360 36361 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 36362 Specifies whether a DWARF `DW_OP_form_tls_address' location 36363 descriptor may be used to describe emulated TLS control objects. 36364 36365 36366File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 36367 3636817.27 Defining coprocessor specifics for MIPS targets. 36369====================================================== 36370 36371The MIPS specification allows MIPS implementations to have as many as 4 36372coprocessors, each with as many as 32 private registers. GCC supports 36373accessing these registers and transferring values between the registers 36374and memory using asm-ized variables. For example: 36375 36376 register unsigned int cp0count asm ("c0r1"); 36377 unsigned int d; 36378 36379 d = cp0count + 3; 36380 36381 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 36382names may be added as described below, or the default names may be 36383overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 36384 36385 Coprocessor registers are assumed to be epilogue-used; sets to them 36386will be preserved even if it does not appear that the register is used 36387again later in the function. 36388 36389 Another note: according to the MIPS spec, coprocessor 1 (if present) is 36390the FPU. One accesses COP1 registers through standard mips 36391floating-point support; they are not included in this mechanism. 36392 36393 There is one macro used in defining the MIPS coprocessor interface 36394which you may want to override in subtargets; it is described below. 36395 36396 36397File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 36398 3639917.28 Parameters for Precompiled Header Validity Checking 36400========================================================= 36401 36402 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 36403 This hook returns a pointer to the data needed by 36404 `TARGET_PCH_VALID_P' and sets `*SZ' to the size of the data in 36405 bytes. 36406 36407 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 36408 size_t SZ) 36409 This hook checks whether the options used to create a PCH file are 36410 compatible with the current settings. It returns `NULL' if so and 36411 a suitable error message if not. Error messages will be presented 36412 to the user and must be localized using `_(MSG)'. 36413 36414 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY' 36415 when the PCH file was created and SZ is the size of that data in 36416 bytes. It's safe to assume that the data was created by the same 36417 version of the compiler, so no format checking is needed. 36418 36419 The default definition of `default_pch_valid_p' should be suitable 36420 for most targets. 36421 36422 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 36423 PCH_FLAGS) 36424 If this hook is nonnull, the default implementation of 36425 `TARGET_PCH_VALID_P' will use it to check for compatible values of 36426 `target_flags'. PCH_FLAGS specifies the value that `target_flags' 36427 had when the PCH file was created. The return value is the same 36428 as for `TARGET_PCH_VALID_P'. 36429 36430 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 36431 Called before writing out a PCH file. If the target has some 36432 garbage-collected data that needs to be in a particular state on 36433 PCH loads, it can use this hook to enforce that state. Very few 36434 targets need to do anything here. 36435 36436 36437File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 36438 3643917.29 C++ ABI parameters 36440======================== 36441 36442 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 36443 Define this hook to override the integer type used for guard 36444 variables. These are used to implement one-time construction of 36445 static objects. The default is long_long_integer_type_node. 36446 36447 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 36448 This hook determines how guard variables are used. It should 36449 return `false' (the default) if the first byte should be used. A 36450 return value of `true' indicates that only the least significant 36451 bit should be used. 36452 36453 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 36454 This hook returns the size of the cookie to use when allocating an 36455 array whose elements have the indicated TYPE. Assumes that it is 36456 already known that a cookie is needed. The default is `max(sizeof 36457 (size_t), alignof(type))', as defined in section 2.7 of the 36458 IA64/Generic C++ ABI. 36459 36460 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 36461 This hook should return `true' if the element size should be 36462 stored in array cookies. The default is to return `false'. 36463 36464 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 36465 IMPORT_EXPORT) 36466 If defined by a backend this hook allows the decision made to 36467 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 36468 contain 1 if the class is going to be exported, -1 if it is going 36469 to be imported and 0 otherwise. This function should return the 36470 modified value and perform any other actions necessary to support 36471 the backend's targeted operating system. 36472 36473 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 36474 This hook should return `true' if constructors and destructors 36475 return the address of the object created/destroyed. The default 36476 is to return `false'. 36477 36478 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 36479 This hook returns true if the key method for a class (i.e., the 36480 method which, if defined in the current translation unit, causes 36481 the virtual table to be emitted) may be an inline function. Under 36482 the standard Itanium C++ ABI the key method may be an inline 36483 function so long as the function is not declared inline in the 36484 class definition. Under some variants of the ABI, an inline 36485 function can never be the key method. The default is to return 36486 `true'. 36487 36488 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 36489 DECL) 36490 DECL is a virtual table, virtual table table, typeinfo object, or 36491 other similar implicit class data object that will be emitted with 36492 external linkage in this translation unit. No ELF visibility has 36493 been explicitly specified. If the target needs to specify a 36494 visibility other than that of the containing class, use this hook 36495 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'. 36496 36497 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 36498 This hook returns true (the default) if virtual tables and other 36499 similar implicit class data objects are always COMDAT if they have 36500 external linkage. If this hook returns false, then class data for 36501 classes whose virtual table will be emitted in only one translation 36502 unit will not be COMDAT. 36503 36504 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 36505 This hook returns true (the default) if the RTTI information for 36506 the basic types which is defined in the C++ runtime should always 36507 be COMDAT, false if it should not be COMDAT. 36508 36509 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 36510 This hook returns true if `__aeabi_atexit' (as defined by the ARM 36511 EABI) should be used to register static destructors when 36512 `-fuse-cxa-atexit' is in effect. The default is to return false 36513 to use `__cxa_atexit'. 36514 36515 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 36516 This hook returns true if the target `atexit' function can be used 36517 in the same manner as `__cxa_atexit' to register C++ static 36518 destructors. This requires that `atexit'-registered functions in 36519 shared libraries are run in the correct order when the libraries 36520 are unloaded. The default is to return false. 36521 36522 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 36523 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has 36524 just been defined. Use this hook to make adjustments to the class 36525 (eg, tweak visibility or perform any other required target 36526 modifications). 36527 36528 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 36529 Return target-specific mangling context of DECL or `NULL_TREE'. 36530 36531 36532File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 36533 3653417.30 Adding support for named address spaces 36535============================================= 36536 36537The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 36538committee, `Programming Languages - C - Extensions to support embedded 36539processors', specifies a syntax for embedded processors to specify 36540alternate address spaces. You can configure a GCC port to support 36541section 5.1 of the draft report to add support for address spaces other 36542than the default address space. These address spaces are new keywords 36543that are similar to the `volatile' and `const' type attributes. 36544 36545 Pointers to named address spaces can have a different size than 36546pointers to the generic address space. 36547 36548 For example, the SPU port uses the `__ea' address space to refer to 36549memory in the host processor, rather than memory local to the SPU 36550processor. Access to memory in the `__ea' address space involves 36551issuing DMA operations to move data between the host processor and the 36552local processor memory address space. Pointers in the `__ea' address 36553space are either 32 bits or 64 bits based on the `-mea32' or `-mea64' 36554switches (native SPU pointers are always 32 bits). 36555 36556 Internally, address spaces are represented as a small integer in the 36557range 0 to 15 with address space 0 being reserved for the generic 36558address space. 36559 36560 To register a named address space qualifier keyword with the C front 36561end, the target may call the `c_register_addr_space' routine. For 36562example, the SPU port uses the following to declare `__ea' as the 36563keyword for named address space #1: 36564 #define ADDR_SPACE_EA 1 36565 c_register_addr_space ("__ea", ADDR_SPACE_EA); 36566 36567 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_POINTER_MODE 36568 (addr_space_t ADDRESS_SPACE) 36569 Define this to return the machine mode to use for pointers to 36570 ADDRESS_SPACE if the target supports named address spaces. The 36571 default version of this hook returns `ptr_mode' for the generic 36572 address space only. 36573 36574 -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE 36575 (addr_space_t ADDRESS_SPACE) 36576 Define this to return the machine mode to use for addresses in 36577 ADDRESS_SPACE if the target supports named address spaces. The 36578 default version of this hook returns `Pmode' for the generic 36579 address space only. 36580 36581 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (enum 36582 machine_mode MODE, addr_space_t AS) 36583 Define this to return nonzero if the port can handle pointers with 36584 machine mode MODE to address space AS. This target hook is the 36585 same as the `TARGET_VALID_POINTER_MODE' target hook, except that 36586 it includes explicit named address space support. The default 36587 version of this hook returns true for the modes returned by either 36588 the `TARGET_ADDR_SPACE_POINTER_MODE' or 36589 `TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given 36590 address space. 36591 36592 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (enum 36593 machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 36594 Define this to return true if EXP is a valid address for mode MODE 36595 in the named address space AS. The STRICT parameter says whether 36596 strict addressing is in effect after reload has finished. This 36597 target hook is the same as the `TARGET_LEGITIMATE_ADDRESS_P' 36598 target hook, except that it includes explicit named address space 36599 support. 36600 36601 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 36602 OLDX, enum machine_mode MODE, addr_space_t AS) 36603 Define this to modify an invalid address X to be a valid address 36604 with mode MODE in the named address space AS. This target hook is 36605 the same as the `TARGET_LEGITIMIZE_ADDRESS' target hook, except 36606 that it includes explicit named address space support. 36607 36608 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 36609 addr_space_t SUPERSET) 36610 Define this to return whether the SUBSET named address space is 36611 contained within the SUPERSET named address space. Pointers to a 36612 named address space that is a subset of another named address space 36613 will be converted automatically without a cast if used together in 36614 arithmetic operations. Pointers to a superset address space can be 36615 converted to pointers to a subset address space via explicit casts. 36616 36617 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 36618 tree TO_TYPE) 36619 Define this to convert the pointer expression represented by the 36620 RTL OP with type FROM_TYPE that points to a named address space to 36621 a new pointer expression with type TO_TYPE that points to a 36622 different named address space. When this hook it called, it is 36623 guaranteed that one of the two address spaces is a subset of the 36624 other, as determined by the `TARGET_ADDR_SPACE_SUBSET_P' target 36625 hook. 36626 36627 36628File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 36629 3663017.31 Miscellaneous Parameters 36631============================== 36632 36633Here are several miscellaneous parameters. 36634 36635 -- Macro: HAS_LONG_COND_BRANCH 36636 Define this boolean macro to indicate whether or not your 36637 architecture has conditional branches that can span all of memory. 36638 It is used in conjunction with an optimization that partitions hot 36639 and cold basic blocks into separate sections of the executable. 36640 If this macro is set to false, gcc will convert any conditional 36641 branches that attempt to cross between sections into unconditional 36642 branches or indirect jumps. 36643 36644 -- Macro: HAS_LONG_UNCOND_BRANCH 36645 Define this boolean macro to indicate whether or not your 36646 architecture has unconditional branches that can span all of 36647 memory. It is used in conjunction with an optimization that 36648 partitions hot and cold basic blocks into separate sections of the 36649 executable. If this macro is set to false, gcc will convert any 36650 unconditional branches that attempt to cross between sections into 36651 indirect jumps. 36652 36653 -- Macro: CASE_VECTOR_MODE 36654 An alias for a machine mode name. This is the machine mode that 36655 elements of a jump-table should have. 36656 36657 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 36658 Optional: return the preferred mode for an `addr_diff_vec' when 36659 the minimum and maximum offset are known. If you define this, it 36660 enables extra code in branch shortening to deal with 36661 `addr_diff_vec'. To make this work, you also have to define 36662 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit. 36663 The BODY argument is provided so that the offset_unsigned and scale 36664 flags can be updated. 36665 36666 -- Macro: CASE_VECTOR_PC_RELATIVE 36667 Define this macro to be a C expression to indicate when jump-tables 36668 should contain relative addresses. You need not define this macro 36669 if jump-tables never contain relative addresses, or jump-tables 36670 should contain relative addresses only when `-fPIC' or `-fPIC' is 36671 in effect. 36672 36673 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 36674 This function return the smallest number of different values for 36675 which it is best to use a jump-table instead of a tree of 36676 conditional branches. The default is four for machines with a 36677 `casesi' instruction and five otherwise. This is best for most 36678 machines. 36679 36680 -- Macro: WORD_REGISTER_OPERATIONS 36681 Define this macro if operations between registers with integral 36682 mode smaller than a word are always performed on the entire 36683 register. Most RISC machines have this property and most CISC 36684 machines do not. 36685 36686 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 36687 Define this macro to be a C expression indicating when insns that 36688 read memory in MEM_MODE, an integral mode narrower than a word, 36689 set the bits outside of MEM_MODE to be either the sign-extension 36690 or the zero-extension of the data read. Return `SIGN_EXTEND' for 36691 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND' 36692 for which it zero-extends, and `UNKNOWN' for other modes. 36693 36694 This macro is not called with MEM_MODE non-integral or with a width 36695 greater than or equal to `BITS_PER_WORD', so you may return any 36696 value in this case. Do not define this macro if it would always 36697 return `UNKNOWN'. On machines where this macro is defined, you 36698 will normally define it as the constant `SIGN_EXTEND' or 36699 `ZERO_EXTEND'. 36700 36701 You may return a non-`UNKNOWN' value even if for some hard 36702 registers the sign extension is not performed, if for the 36703 `REGNO_REG_CLASS' of these hard registers 36704 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 36705 MEM_MODE and the TO mode is any integral mode larger than this but 36706 not larger than `word_mode'. 36707 36708 You must return `UNKNOWN' if for some hard registers that allow 36709 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change 36710 to `word_mode', but that they can change to another integral mode 36711 that is larger then MEM_MODE but still smaller than `word_mode'. 36712 36713 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 36714 Define this macro if loading short immediate values into registers 36715 sign extends. 36716 36717 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum 36718 machine_mode MODE) 36719 When `-ffast-math' is in effect, GCC tries to optimize divisions 36720 by the same divisor, by turning them into multiplications by the 36721 reciprocal. This target hook specifies the minimum number of 36722 divisions that should be there for GCC to perform the optimization 36723 for a variable of mode MODE. The default implementation returns 3 36724 if the machine has an instruction for the division, and 2 if it 36725 does not. 36726 36727 -- Macro: MOVE_MAX 36728 The maximum number of bytes that a single instruction can move 36729 quickly between memory and registers or between two memory 36730 locations. 36731 36732 -- Macro: MAX_MOVE_MAX 36733 The maximum number of bytes that a single instruction can move 36734 quickly between memory and registers or between two memory 36735 locations. If this is undefined, the default is `MOVE_MAX'. 36736 Otherwise, it is the constant value that is the largest value that 36737 `MOVE_MAX' can have at run-time. 36738 36739 -- Macro: SHIFT_COUNT_TRUNCATED 36740 A C expression that is nonzero if on this machine the number of 36741 bits actually used for the count of a shift operation is equal to 36742 the number of bits needed to represent the size of the object 36743 being shifted. When this macro is nonzero, the compiler will 36744 assume that it is safe to omit a sign-extend, zero-extend, and 36745 certain bitwise `and' instructions that truncates the count of a 36746 shift operation. On machines that have instructions that act on 36747 bit-fields at variable positions, which may include `bit test' 36748 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables 36749 deletion of truncations of the values that serve as arguments to 36750 bit-field instructions. 36751 36752 If both types of instructions truncate the count (for shifts) and 36753 position (for bit-field operations), or if no variable-position 36754 bit-field instructions exist, you should define this macro. 36755 36756 However, on some machines, such as the 80386 and the 680x0, 36757 truncation only applies to shift operations and not the (real or 36758 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' 36759 to be zero on such machines. Instead, add patterns to the `md' 36760 file that include the implied truncation of the shift instructions. 36761 36762 You need not define this macro if it would always have the value 36763 of zero. 36764 36765 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 36766 (enum machine_mode MODE) 36767 This function describes how the standard shift patterns for MODE 36768 deal with shifts by negative amounts or by more than the width of 36769 the mode. *Note shift patterns::. 36770 36771 On many machines, the shift patterns will apply a mask M to the 36772 shift count, meaning that a fixed-width shift of X by Y is 36773 equivalent to an arbitrary-width shift of X by Y & M. If this is 36774 true for mode MODE, the function should return M, otherwise it 36775 should return 0. A return value of 0 indicates that no particular 36776 behavior is guaranteed. 36777 36778 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does 36779 _not_ apply to general shift rtxes; it applies only to instructions 36780 that are generated by the named shift patterns. 36781 36782 The default implementation of this function returns 36783 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0 36784 otherwise. This definition is always safe, but if 36785 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 36786 nevertheless truncate the shift count, you may get better code by 36787 overriding it. 36788 36789 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 36790 A C expression which is nonzero if on this machine it is safe to 36791 "convert" an integer of INPREC bits to one of OUTPREC bits (where 36792 OUTPREC is smaller than INPREC) by merely operating on it as if it 36793 had only OUTPREC bits. 36794 36795 On many machines, this expression can be 1. 36796 36797 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 36798 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 36799 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in 36800 such cases may improve things. 36801 36802 -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE, 36803 enum machine_mode REP_MODE) 36804 The representation of an integral mode can be such that the values 36805 are always extended to a wider integral mode. Return 36806 `SIGN_EXTEND' if values of MODE are represented in sign-extended 36807 form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none 36808 of the targets use zero-extended representation this way so unlike 36809 `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return 36810 either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to 36811 REP_MODE so that REP_MODE is not the next widest integral mode and 36812 currently we take advantage of this fact.) 36813 36814 Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value 36815 even if the extension is not performed on certain hard registers 36816 as long as for the `REGNO_REG_CLASS' of these hard registers 36817 `CANNOT_CHANGE_MODE_CLASS' returns nonzero. 36818 36819 Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe 36820 two related properties. If you define `TARGET_MODE_REP_EXTENDED 36821 (mode, word_mode)' you probably also want to define 36822 `LOAD_EXTEND_OP (mode)' to return the same type of extension. 36823 36824 In order to enforce the representation of `mode', 36825 `TRULY_NOOP_TRUNCATION' should return false when truncating to 36826 `mode'. 36827 36828 -- Macro: STORE_FLAG_VALUE 36829 A C expression describing the value returned by a comparison 36830 operator with an integral mode and stored by a store-flag 36831 instruction (`cstoreMODE4') when the condition is true. This 36832 description must apply to _all_ the `cstoreMODE4' patterns and all 36833 the comparison operators whose results have a `MODE_INT' mode. 36834 36835 A value of 1 or -1 means that the instruction implementing the 36836 comparison operator returns exactly 1 or -1 when the comparison is 36837 true and 0 when the comparison is false. Otherwise, the value 36838 indicates which bits of the result are guaranteed to be 1 when the 36839 comparison is true. This value is interpreted in the mode of the 36840 comparison operation, which is given by the mode of the first 36841 operand in the `cstoreMODE4' pattern. Either the low bit or the 36842 sign bit of `STORE_FLAG_VALUE' be on. Presently, only those bits 36843 are used by the compiler. 36844 36845 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 36846 generate code that depends only on the specified bits. It can also 36847 replace comparison operators with equivalent operations if they 36848 cause the required bits to be set, even if the remaining bits are 36849 undefined. For example, on a machine whose comparison operators 36850 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as 36851 `0x80000000', saying that just the sign bit is relevant, the 36852 expression 36853 36854 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 36855 36856 can be converted to 36857 36858 (ashift:SI X (const_int N)) 36859 36860 where N is the appropriate shift count to move the bit being 36861 tested into the sign bit. 36862 36863 There is no way to describe a machine that always sets the 36864 low-order bit for a true value, but does not guarantee the value 36865 of any other bits, but we do not know of any machine that has such 36866 an instruction. If you are trying to port GCC to such a machine, 36867 include an instruction to perform a logical-and of the result with 36868 1 in the pattern for the comparison operators and let us know at 36869 <gcc@gcc.gnu.org>. 36870 36871 Often, a machine will have multiple instructions that obtain a 36872 value from a comparison (or the condition codes). Here are rules 36873 to guide the choice of value for `STORE_FLAG_VALUE', and hence the 36874 instructions to be used: 36875 36876 * Use the shortest sequence that yields a valid definition for 36877 `STORE_FLAG_VALUE'. It is more efficient for the compiler to 36878 "normalize" the value (convert it to, e.g., 1 or 0) than for 36879 the comparison operators to do so because there may be 36880 opportunities to combine the normalization with other 36881 operations. 36882 36883 * For equal-length sequences, use a value of 1 or -1, with -1 36884 being slightly preferred on machines with expensive jumps and 36885 1 preferred on other machines. 36886 36887 * As a second choice, choose a value of `0x80000001' if 36888 instructions exist that set both the sign and low-order bits 36889 but do not define the others. 36890 36891 * Otherwise, use a value of `0x80000000'. 36892 36893 Many machines can produce both the value chosen for 36894 `STORE_FLAG_VALUE' and its negation in the same number of 36895 instructions. On those machines, you should also define a pattern 36896 for those cases, e.g., one matching 36897 36898 (set A (neg:M (ne:M B C))) 36899 36900 Some machines can also perform `and' or `plus' operations on 36901 condition code values with less instructions than the corresponding 36902 `cstoreMODE4' insn followed by `and' or `plus'. On those 36903 machines, define the appropriate patterns. Use the names `incscc' 36904 and `decscc', respectively, for the patterns which perform `plus' 36905 or `minus' operations on condition code values. See `rs6000.md' 36906 for some examples. The GNU Superoptimizer can be used to find 36907 such instruction sequences on other machines. 36908 36909 If this macro is not defined, the default value, 1, is used. You 36910 need not define `STORE_FLAG_VALUE' if the machine has no store-flag 36911 instructions, or if the value generated by these instructions is 1. 36912 36913 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 36914 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is 36915 returned when comparison operators with floating-point results are 36916 true. Define this macro on machines that have comparison 36917 operations that return floating-point values. If there are no 36918 such operations, do not define this macro. 36919 36920 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 36921 A C expression that gives a rtx representing the nonzero true 36922 element for vector comparisons. The returned rtx should be valid 36923 for the inner mode of MODE which is guaranteed to be a vector 36924 mode. Define this macro on machines that have vector comparison 36925 operations that return a vector result. If there are no such 36926 operations, do not define this macro. Typically, this macro is 36927 defined as `const1_rtx' or `constm1_rtx'. This macro may return 36928 `NULL_RTX' to prevent the compiler optimizing such vector 36929 comparison operations for the given mode. 36930 36931 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 36932 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 36933 A C expression that indicates whether the architecture defines a 36934 value for `clz' or `ctz' with a zero operand. A result of `0' 36935 indicates the value is undefined. If the value is defined for 36936 only the RTL expression, the macro should evaluate to `1'; if the 36937 value applies also to the corresponding optab entry (which is 36938 normally the case if it expands directly into the corresponding 36939 RTL), then the macro should evaluate to `2'. In the cases where 36940 the value is defined, VALUE should be set to this value. 36941 36942 If this macro is not defined, the value of `clz' or `ctz' at zero 36943 is assumed to be undefined. 36944 36945 This macro must be defined if the target's expansion for `ffs' 36946 relies on a particular value to get correct results. Otherwise it 36947 is not necessary, though it may be used to optimize some corner 36948 cases, and to provide a default expansion for the `ffs' optab. 36949 36950 Note that regardless of this macro the "definedness" of `clz' and 36951 `ctz' at zero do _not_ extend to the builtin functions visible to 36952 the user. Thus one may be free to adjust the value at will to 36953 match the target expansion of these operations without fear of 36954 breaking the API. 36955 36956 -- Macro: Pmode 36957 An alias for the machine mode for pointers. On most machines, 36958 define this to be the integer mode corresponding to the width of a 36959 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit 36960 machines. On some machines you must define this to be one of the 36961 partial integer modes, such as `PSImode'. 36962 36963 The width of `Pmode' must be at least as large as the value of 36964 `POINTER_SIZE'. If it is not equal, you must define the macro 36965 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 36966 `Pmode'. 36967 36968 -- Macro: FUNCTION_MODE 36969 An alias for the machine mode used for memory references to 36970 functions being called, in `call' RTL expressions. On most CISC 36971 machines, where an instruction can begin at any byte address, this 36972 should be `QImode'. On most RISC machines, where all instructions 36973 have fixed size and alignment, this should be a mode with the same 36974 size and alignment as the machine instruction words - typically 36975 `SImode' or `HImode'. 36976 36977 -- Macro: STDC_0_IN_SYSTEM_HEADERS 36978 In normal operation, the preprocessor expands `__STDC__' to the 36979 constant 1, to signify that GCC conforms to ISO Standard C. On 36980 some hosts, like Solaris, the system compiler uses a different 36981 convention, where `__STDC__' is normally 0, but is 1 if the user 36982 specifies strict conformance to the C Standard. 36983 36984 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 36985 convention when processing system header files, but when 36986 processing user files `__STDC__' will always expand to 1. 36987 36988 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 36989 Define this hook to return the name of a header file to be 36990 included at the start of all compilations, as if it had been 36991 included with `#include <FILE>'. If this hook returns `NULL', or 36992 is not defined, or the header is not found, or if the user 36993 specifies `-ffreestanding' or `-nostdinc', no header is included. 36994 36995 This hook can be used together with a header provided by the 36996 system C library to implement ISO C requirements for certain 36997 macros to be predefined that describe properties of the whole 36998 implementation rather than just the compiler. 36999 37000 -- Macro: NO_IMPLICIT_EXTERN_C 37001 Define this macro if the system header files support C++ as well 37002 as C. This macro inhibits the usual method of using system header 37003 files in C++, which is to pretend that the file's contents are 37004 enclosed in `extern "C" {...}'. 37005 37006 -- Macro: REGISTER_TARGET_PRAGMAS () 37007 Define this macro if you want to implement any target-specific 37008 pragmas. If defined, it is a C expression which makes a series of 37009 calls to `c_register_pragma' or `c_register_pragma_with_expansion' 37010 for each pragma. The macro may also do any setup required for the 37011 pragmas. 37012 37013 The primary reason to define this macro is to provide 37014 compatibility with other compilers for the same target. In 37015 general, we discourage definition of target-specific pragmas for 37016 GCC. 37017 37018 If the pragma can be implemented by attributes then you should 37019 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as 37020 well. 37021 37022 Preprocessor macros that appear on pragma lines are not expanded. 37023 All `#pragma' directives that do not match any registered pragma 37024 are silently ignored, unless the user specifies 37025 `-Wunknown-pragmas'. 37026 37027 -- Function: void c_register_pragma (const char *SPACE, const char 37028 *NAME, void (*CALLBACK) (struct cpp_reader *)) 37029 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 37030 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 37031 Each call to `c_register_pragma' or 37032 `c_register_pragma_with_expansion' establishes one pragma. The 37033 CALLBACK routine will be called when the preprocessor encounters a 37034 pragma of the form 37035 37036 #pragma [SPACE] NAME ... 37037 37038 SPACE is the case-sensitive namespace of the pragma, or `NULL' to 37039 put the pragma in the global namespace. The callback routine 37040 receives PFILE as its first argument, which can be passed on to 37041 cpplib's functions if necessary. You can lex tokens after the 37042 NAME by calling `pragma_lex'. Tokens that are not read by the 37043 callback will be silently ignored. The end of the line is 37044 indicated by a token of type `CPP_EOF'. Macro expansion occurs on 37045 the arguments of pragmas registered with 37046 `c_register_pragma_with_expansion' but not on the arguments of 37047 pragmas registered with `c_register_pragma'. 37048 37049 Note that the use of `pragma_lex' is specific to the C and C++ 37050 compilers. It will not work in the Java or Fortran compilers, or 37051 any other language compilers for that matter. Thus if 37052 `pragma_lex' is going to be called from target-specific code, it 37053 must only be done so when building the C and C++ compilers. This 37054 can be done by defining the variables `c_target_objs' and 37055 `cxx_target_objs' in the target entry in the `config.gcc' file. 37056 These variables should name the target-specific, language-specific 37057 object file which contains the code that uses `pragma_lex'. Note 37058 it will also be necessary to add a rule to the makefile fragment 37059 pointed to by `tmake_file' that shows how to build this object 37060 file. 37061 37062 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 37063 Define this macro if macros should be expanded in the arguments of 37064 `#pragma pack'. 37065 37066 -- Macro: TARGET_DEFAULT_PACK_STRUCT 37067 If your target requires a structure packing default other than 0 37068 (meaning the machine default), define this macro to the necessary 37069 value (in bytes). This must be a value that would also be valid 37070 to use with `#pragma pack()' (that is, a small power of two). 37071 37072 -- Macro: DOLLARS_IN_IDENTIFIERS 37073 Define this macro to control use of the character `$' in 37074 identifier names for the C family of languages. 0 means `$' is 37075 not allowed by default; 1 means it is allowed. 1 is the default; 37076 there is no need to define this macro in that case. 37077 37078 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 37079 Define this macro as a C expression that is nonzero if it is safe 37080 for the delay slot scheduler to place instructions in the delay 37081 slot of INSN, even if they appear to use a resource set or 37082 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC 37083 knows that every `call_insn' has this behavior. On machines where 37084 some `insn' or `jump_insn' is really a function call and hence has 37085 this behavior, you should define this macro. 37086 37087 You need not define this macro if it would always return zero. 37088 37089 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 37090 Define this macro as a C expression that is nonzero if it is safe 37091 for the delay slot scheduler to place instructions in the delay 37092 slot of INSN, even if they appear to set or clobber a resource 37093 referenced in INSN. INSN is always a `jump_insn' or an `insn'. 37094 On machines where some `insn' or `jump_insn' is really a function 37095 call and its operands are registers whose use is actually in the 37096 subroutine it calls, you should define this macro. Doing so 37097 allows the delay slot scheduler to move instructions which copy 37098 arguments into the argument registers into the delay slot of INSN. 37099 37100 You need not define this macro if it would always return zero. 37101 37102 -- Macro: MULTIPLE_SYMBOL_SPACES 37103 Define this macro as a C expression that is nonzero if, in some 37104 cases, global symbols from one translation unit may not be bound 37105 to undefined symbols in another translation unit without user 37106 intervention. For instance, under Microsoft Windows symbols must 37107 be explicitly imported from shared libraries (DLLs). 37108 37109 You need not define this macro if it would always evaluate to zero. 37110 37111 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree 37112 INPUTS, tree CLOBBERS) 37113 This target hook should add to CLOBBERS `STRING_CST' trees for any 37114 hard regs the port wishes to automatically clobber for an asm. It 37115 should return the result of the last `tree_cons' used to add a 37116 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the 37117 corresponding parameters to the asm and may be inspected to avoid 37118 clobbering a register that is an input or output of the asm. You 37119 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test 37120 for overlap with regards to asm-declared registers. 37121 37122 -- Macro: MATH_LIBRARY 37123 Define this macro as a C string constant for the linker argument 37124 to link in the system math library, minus the initial `"-l"', or 37125 `""' if the target does not have a separate math library. 37126 37127 You need only define this macro if the default of `"m"' is wrong. 37128 37129 -- Macro: LIBRARY_PATH_ENV 37130 Define this macro as a C string constant for the environment 37131 variable that specifies where the linker should look for libraries. 37132 37133 You need only define this macro if the default of `"LIBRARY_PATH"' 37134 is wrong. 37135 37136 -- Macro: TARGET_POSIX_IO 37137 Define this macro if the target supports the following POSIX file 37138 functions, access, mkdir and file locking with fcntl / F_SETLKW. 37139 Defining `TARGET_POSIX_IO' will enable the test coverage code to 37140 use file locking when exiting a program, which avoids race 37141 conditions if the program has forked. It will also create 37142 directories at run-time for cross-profiling. 37143 37144 -- Macro: MAX_CONDITIONAL_EXECUTE 37145 A C expression for the maximum number of instructions to execute 37146 via conditional execution instructions instead of a branch. A 37147 value of `BRANCH_COST'+1 is the default if the machine does not 37148 use cc0, and 1 if it does use cc0. 37149 37150 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 37151 Used if the target needs to perform machine-dependent 37152 modifications on the conditionals used for turning basic blocks 37153 into conditionally executed code. CE_INFO points to a data 37154 structure, `struct ce_if_block', which contains information about 37155 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the 37156 tests that are used for converting the then-block and the 37157 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a 37158 null pointer if the tests cannot be converted. 37159 37160 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 37161 FALSE_EXPR) 37162 Like `IFCVT_MODIFY_TESTS', but used when converting more 37163 complicated if-statements into conditions combined by `and' and 37164 `or' operations. BB contains the basic block that contains the 37165 test that is currently being processed and about to be turned into 37166 a condition. 37167 37168 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 37169 A C expression to modify the PATTERN of an INSN that is to be 37170 converted to conditional execution format. CE_INFO points to a 37171 data structure, `struct ce_if_block', which contains information 37172 about the currently processed blocks. 37173 37174 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 37175 A C expression to perform any final machine dependent 37176 modifications in converting code to conditional execution. The 37177 involved basic blocks can be found in the `struct ce_if_block' 37178 structure that is pointed to by CE_INFO. 37179 37180 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 37181 A C expression to cancel any machine dependent modifications in 37182 converting code to conditional execution. The involved basic 37183 blocks can be found in the `struct ce_if_block' structure that is 37184 pointed to by CE_INFO. 37185 37186 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 37187 A C expression to initialize any machine specific data for 37188 if-conversion of the if-block in the `struct ce_if_block' 37189 structure that is pointed to by CE_INFO. 37190 37191 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 37192 If non-null, this hook performs a target-specific pass over the 37193 instruction stream. The compiler will run it at all optimization 37194 levels, just before the point at which it normally does 37195 delayed-branch scheduling. 37196 37197 The exact purpose of the hook varies from target to target. Some 37198 use it to do transformations that are necessary for correctness, 37199 such as laying out in-function constant pools or avoiding hardware 37200 hazards. Others use it as an opportunity to do some 37201 machine-dependent optimizations. 37202 37203 You need not implement the hook if it has nothing to do. The 37204 default definition is null. 37205 37206 -- Target Hook: void TARGET_INIT_BUILTINS (void) 37207 Define this hook if you have any machine-specific built-in 37208 functions that need to be defined. It should be a function that 37209 performs the necessary setup. 37210 37211 Machine specific built-in functions can be useful to expand 37212 special machine instructions that would otherwise not normally be 37213 generated because they have no equivalent in the source language 37214 (for example, SIMD vector instructions or prefetch instructions). 37215 37216 To create a built-in function, call the function 37217 `lang_hooks.builtin_function' which is defined by the language 37218 front end. You can use any type nodes set up by 37219 `build_common_tree_nodes'; only language front ends that use those 37220 two functions will call `TARGET_INIT_BUILTINS'. 37221 37222 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 37223 INITIALIZE_P) 37224 Define this hook if you have any machine-specific built-in 37225 functions that need to be defined. It should be a function that 37226 returns the builtin function declaration for the builtin function 37227 code CODE. If there is no such builtin and it cannot be 37228 initialized at this time if INITIALIZE_P is true the function 37229 should return `NULL_TREE'. If CODE is out of range the function 37230 should return `error_mark_node'. 37231 37232 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 37233 SUBTARGET, enum machine_mode MODE, int IGNORE) 37234 Expand a call to a machine specific built-in function that was set 37235 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the 37236 function call; the result should go to TARGET if that is 37237 convenient, and have mode MODE if that is convenient. SUBTARGET 37238 may be used as the target for computing one of EXP's operands. 37239 IGNORE is nonzero if the value is to be ignored. This function 37240 should return the result of the call to the built-in function. 37241 37242 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 37243 LOC, tree FNDECL, void *ARGLIST) 37244 Select a replacement for a machine specific built-in function that 37245 was set up by `TARGET_INIT_BUILTINS'. This is done _before_ 37246 regular type checking, and so allows the target to implement a 37247 crude form of function overloading. FNDECL is the declaration of 37248 the built-in function. ARGLIST is the list of arguments passed to 37249 the built-in function. The result is a complete expression that 37250 implements the operation, usually another `CALL_EXPR'. ARGLIST 37251 really has type `VEC(tree,gc)*' 37252 37253 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, 37254 tree *ARGP, bool IGNORE) 37255 Fold a call to a machine specific built-in function that was set 37256 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 37257 built-in function. N_ARGS is the number of arguments passed to 37258 the function; the arguments themselves are pointed to by ARGP. 37259 The result is another tree containing a simplified expression for 37260 the call's result. If IGNORE is true the value will be ignored. 37261 37262 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 37263 DECL2) 37264 This hook is used to compare the target attributes in two 37265 functions to determine which function's features get higher 37266 priority. This is used during function multi-versioning to figure 37267 out the order in which two versions must be dispatched. A 37268 function version with a higher priority is checked for dispatching 37269 earlier. DECL1 and DECL2 are the two function decls that will be 37270 compared. 37271 37272 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 37273 *DECL) 37274 This hook is used to get the dispatcher function for a set of 37275 function versions. The dispatcher function is called to invoke 37276 the right function version at run-time. DECL is one version from a 37277 set of semantically identical versions. 37278 37279 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 37280 *ARG) 37281 This hook is used to generate the dispatcher logic to invoke the 37282 right function version at run-time for a given set of function 37283 versions. ARG points to the callgraph node of the dispatcher 37284 function whose body must be generated. 37285 37286 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const_rtx 37287 INSN) 37288 Take an instruction in INSN and return NULL if it is valid within a 37289 low-overhead loop, otherwise return a string explaining why doloop 37290 could not be applied. 37291 37292 Many targets use special registers for low-overhead looping. For 37293 any instruction that clobbers these this function should return a 37294 string indicating the reason why the doloop could not be applied. 37295 By default, the RTL loop optimizer does not use a present doloop 37296 pattern for loops containing function calls or branch on table 37297 instructions. 37298 37299 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx INSN) 37300 Take an instruction in INSN and return `false' if the instruction 37301 is not appropriate as a combination of two or more instructions. 37302 The default is to accept all instructions. 37303 37304 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2) 37305 Take a branch insn in BRANCH1 and another in BRANCH2. Return true 37306 if redirecting BRANCH1 to the destination of BRANCH2 is possible. 37307 37308 On some targets, branches may have a limited range. Optimizing the 37309 filling of delay slots can result in branches being redirected, 37310 and this may in turn cause a branch offset to overflow. 37311 37312 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const_rtx FOLLOWER, 37313 const_rtx FOLLOWEE) 37314 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 37315 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 37316 For example, on some targets, certain kinds of branches can't be 37317 made to follow through a hot/cold partitioning. 37318 37319 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 37320 This target hook returns `true' if X is considered to be 37321 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 37322 PA doesn't consider PLUS to be commutative inside a MEM. 37323 OUTER_CODE is the rtx code of the enclosing rtl, if known, 37324 otherwise it is UNKNOWN. 37325 37326 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 37327 When the initial value of a hard register has been copied in a 37328 pseudo register, it is often not necessary to actually allocate 37329 another register to this pseudo register, because the original 37330 hard register or a stack slot it has been saved into can be used. 37331 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 37332 allocation once for each hard register that had its initial value 37333 copied by using `get_func_hard_reg_initial_val' or 37334 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if 37335 you don't want to do any special allocation, a `REG' rtx--that 37336 would typically be the hard register itself, if it is known not to 37337 be clobbered--or a `MEM'. If you are returning a `MEM', this is 37338 only a hint for the allocator; it might decide to use another 37339 register anyways. You may use `current_function_is_leaf' or 37340 `REG_N_SETS' in the hook to determine if the hard register in 37341 question will not be clobbered. The default value of this hook is 37342 `NULL', which disables any special allocation. 37343 37344 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 37345 FLAGS) 37346 This target hook returns nonzero if X, an `unspec' or 37347 `unspec_volatile' operation, might cause a trap. Targets can use 37348 this hook to enhance precision of analysis for `unspec' and 37349 `unspec_volatile' operations. You may call `may_trap_p_1' to 37350 analyze inner elements of X in which case FLAGS should be passed 37351 along. 37352 37353 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 37354 The compiler invokes this hook whenever it changes its current 37355 function context (`cfun'). You can define this function if the 37356 back end needs to perform any initialization or reset actions on a 37357 per-function basis. For example, it may be used to implement 37358 function attributes that affect register usage or code generation 37359 patterns. The argument DECL is the declaration for the new 37360 function context, and may be null to indicate that the compiler 37361 has left a function context and is returning to processing at the 37362 top level. The default hook function does nothing. 37363 37364 GCC sets `cfun' to a dummy function context during initialization 37365 of some parts of the back end. The hook function is not invoked 37366 in this situation; you need not worry about the hook being invoked 37367 recursively, or when the back end is in a partially-initialized 37368 state. `cfun' might be `NULL' to indicate processing at top level, 37369 outside of any function scope. 37370 37371 -- Macro: TARGET_OBJECT_SUFFIX 37372 Define this macro to be a C string representing the suffix for 37373 object files on your target machine. If you do not define this 37374 macro, GCC will use `.o' as the suffix for object files. 37375 37376 -- Macro: TARGET_EXECUTABLE_SUFFIX 37377 Define this macro to be a C string representing the suffix to be 37378 automatically added to executable files on your target machine. 37379 If you do not define this macro, GCC will use the null string as 37380 the suffix for executable files. 37381 37382 -- Macro: COLLECT_EXPORT_LIST 37383 If defined, `collect2' will scan the individual object files 37384 specified on its command line and create an export list for the 37385 linker. Define this macro for systems like AIX, where the linker 37386 discards object files that are not referenced from `main' and uses 37387 export lists. 37388 37389 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 37390 Define this macro to a C expression representing a variant of the 37391 method call MDECL, if Java Native Interface (JNI) methods must be 37392 invoked differently from other methods on your target. For 37393 example, on 32-bit Microsoft Windows, JNI methods must be invoked 37394 using the `stdcall' calling convention and this macro is then 37395 defined as this expression: 37396 37397 build_type_attribute_variant (MDECL, 37398 build_tree_list 37399 (get_identifier ("stdcall"), 37400 NULL)) 37401 37402 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 37403 This target hook returns `true' past the point in which new jump 37404 instructions could be created. On machines that require a 37405 register for every jump such as the SHmedia ISA of SH5, this point 37406 would typically be reload, so this target hook should be defined 37407 to a function such as: 37408 37409 static bool 37410 cannot_modify_jumps_past_reload_p () 37411 { 37412 return (reload_completed || reload_in_progress); 37413 } 37414 37415 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 37416 This target hook returns a register class for which branch target 37417 register optimizations should be applied. All registers in this 37418 class should be usable interchangeably. After reload, registers 37419 in this class will be re-allocated and loads will be hoisted out 37420 of loops and be subjected to inter-block scheduling. 37421 37422 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 37423 AFTER_PROLOGUE_EPILOGUE_GEN) 37424 Branch target register optimization will by default exclude 37425 callee-saved registers that are not already live during the 37426 current function; if this target hook returns true, they will be 37427 included. The target code must than make sure that all target 37428 registers in the class returned by 37429 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are 37430 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and 37431 epilogues have already been generated. Note, even if you only 37432 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still 37433 are likely to have to make special provisions in 37434 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 37435 target registers. 37436 37437 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 37438 This target hook returns true if the target supports conditional 37439 execution. This target hook is required only when the target has 37440 several different modes and they have different conditional 37441 execution capability, such as ARM. 37442 37443 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 37444 struct loop *LOOP) 37445 This target hook returns a new value for the number of times LOOP 37446 should be unrolled. The parameter NUNROLL is the number of times 37447 the loop is to be unrolled. The parameter LOOP is a pointer to the 37448 loop, which is going to be checked for unrolling. This target hook 37449 is required only when the target has special constraints like 37450 maximum number of memory accesses. 37451 37452 -- Macro: POWI_MAX_MULTS 37453 If defined, this macro is interpreted as a signed integer C 37454 expression that specifies the maximum number of floating point 37455 multiplications that should be emitted when expanding 37456 exponentiation by an integer constant inline. When this value is 37457 defined, exponentiation requiring more than this number of 37458 multiplications is implemented by calling the system library's 37459 `pow', `powf' or `powl' routines. The default value places no 37460 upper bound on the multiplication count. 37461 37462 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 37463 *IPREFIX, int STDINC) 37464 This target hook should register any extra include files for the 37465 target. The parameter STDINC indicates if normal include files 37466 are present. The parameter SYSROOT is the system root directory. 37467 The parameter IPREFIX is the prefix for the gcc directory. 37468 37469 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 37470 char *IPREFIX, int STDINC) 37471 This target hook should register any extra include files for the 37472 target before any standard headers. The parameter STDINC 37473 indicates if normal include files are present. The parameter 37474 SYSROOT is the system root directory. The parameter IPREFIX is 37475 the prefix for the gcc directory. 37476 37477 -- Macro: void TARGET_OPTF (char *PATH) 37478 This target hook should register special include paths for the 37479 target. The parameter PATH is the include to register. On Darwin 37480 systems, this is used for Framework includes, which have semantics 37481 that are different from `-I'. 37482 37483 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 37484 This target macro returns `true' if it is safe to use a local alias 37485 for a virtual function FNDECL when constructing thunks, `false' 37486 otherwise. By default, the macro returns `true' for all 37487 functions, if a target supports aliases (i.e. defines 37488 `ASM_OUTPUT_DEF'), `false' otherwise, 37489 37490 -- Macro: TARGET_FORMAT_TYPES 37491 If defined, this macro is the name of a global variable containing 37492 target-specific format checking information for the `-Wformat' 37493 option. The default is to have no target-specific format checks. 37494 37495 -- Macro: TARGET_N_FORMAT_TYPES 37496 If defined, this macro is the number of entries in 37497 `TARGET_FORMAT_TYPES'. 37498 37499 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 37500 If defined, this macro is the name of a global variable containing 37501 target-specific format overrides for the `-Wformat' option. The 37502 default is to have no target-specific format overrides. If defined, 37503 `TARGET_FORMAT_TYPES' must be defined, too. 37504 37505 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 37506 If defined, this macro specifies the number of entries in 37507 `TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 37508 37509 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 37510 If defined, this macro specifies the optional initialization 37511 routine for target specific customizations of the system printf 37512 and scanf formatter settings. 37513 37514 -- Target Hook: bool TARGET_RELAXED_ORDERING 37515 If set to `true', means that the target's memory model does not 37516 guarantee that loads which do not depend on one another will access 37517 main memory in the order of the instruction stream; if ordering is 37518 important, an explicit memory barrier must be used. This is true 37519 of many recent processors which implement a policy of "relaxed," 37520 "weak," or "release" memory consistency, such as Alpha, PowerPC, 37521 and ia64. The default is `false'. 37522 37523 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 37524 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 37525 If defined, this macro returns the diagnostic message when it is 37526 illegal to pass argument VAL to function FUNCDECL with prototype 37527 TYPELIST. 37528 37529 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 37530 FROMTYPE, const_tree TOTYPE) 37531 If defined, this macro returns the diagnostic message when it is 37532 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity 37533 should be determined by the front end. 37534 37535 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 37536 const_tree TYPE) 37537 If defined, this macro returns the diagnostic message when it is 37538 invalid to apply operation OP (where unary plus is denoted by 37539 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity 37540 should be determined by the front end. 37541 37542 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 37543 const_tree TYPE1, const_tree TYPE2) 37544 If defined, this macro returns the diagnostic message when it is 37545 invalid to apply operation OP to operands of types TYPE1 and 37546 TYPE2, or `NULL' if validity should be determined by the front end. 37547 37548 -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree 37549 TYPE) 37550 If defined, this macro returns the diagnostic message when it is 37551 invalid for functions to include parameters of type TYPE, or 37552 `NULL' if validity should be determined by the front end. This is 37553 currently used only by the C and C++ front ends. 37554 37555 -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree 37556 TYPE) 37557 If defined, this macro returns the diagnostic message when it is 37558 invalid for functions to have return type TYPE, or `NULL' if 37559 validity should be determined by the front end. This is currently 37560 used only by the C and C++ front ends. 37561 37562 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 37563 If defined, this target hook returns the type to which values of 37564 TYPE should be promoted when they appear in expressions, analogous 37565 to the integer promotions, or `NULL_TREE' to use the front end's 37566 normal promotion rules. This hook is useful when there are 37567 target-specific types with special promotion rules. This is 37568 currently used only by the C and C++ front ends. 37569 37570 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 37571 If defined, this hook returns the result of converting EXPR to 37572 TYPE. It should return the converted expression, or `NULL_TREE' 37573 to apply the front end's normal conversion rules. This hook is 37574 useful when there are target-specific types with special 37575 conversion rules. This is currently used only by the C and C++ 37576 front ends. 37577 37578 -- Macro: TARGET_USE_JCR_SECTION 37579 This macro determines whether to use the JCR section to register 37580 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 37581 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, 37582 else 0. 37583 37584 -- Macro: OBJC_JBLEN 37585 This macro determines the size of the objective C jump buffer for 37586 the NeXT runtime. By default, OBJC_JBLEN is defined to an 37587 innocuous value. 37588 37589 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 37590 Define this macro if any target-specific attributes need to be 37591 attached to the functions in `libgcc' that provide low-level 37592 support for call stack unwinding. It is used in declarations in 37593 `unwind-generic.h' and the associated definitions of those 37594 functions. 37595 37596 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 37597 Define this macro to update the current function stack boundary if 37598 necessary. 37599 37600 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 37601 This hook should return an rtx for Dynamic Realign Argument 37602 Pointer (DRAP) if a different argument pointer register is needed 37603 to access the function's argument list due to stack realignment. 37604 Return `NULL' if no DRAP is needed. 37605 37606 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 37607 When optimization is disabled, this hook indicates whether or not 37608 arguments should be allocated to stack slots. Normally, GCC 37609 allocates stacks slots for arguments when not optimizing in order 37610 to make debugging easier. However, when a function is declared 37611 with `__attribute__((naked))', there is no stack frame, and the 37612 compiler cannot safely move arguments from the registers in which 37613 they are passed to the stack. Therefore, this hook should return 37614 true in general, but false for naked functions. The default 37615 implementation always returns true. 37616 37617 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 37618 On some architectures it can take multiple instructions to 37619 synthesize a constant. If there is another constant already in a 37620 register that is close enough in value then it is preferable that 37621 the new constant is computed from this register using immediate 37622 addition or subtraction. We accomplish this through CSE. Besides 37623 the value of the constant we also add a lower and an upper 37624 constant anchor to the available expressions. These are then 37625 queried when encountering new constants. The anchors are computed 37626 by rounding the constant up and down to a multiple of the value of 37627 `TARGET_CONST_ANCHOR'. `TARGET_CONST_ANCHOR' should be the 37628 maximum positive value accepted by immediate-add plus one. We 37629 currently assume that the value of `TARGET_CONST_ANCHOR' is a 37630 power of 2. For example, on MIPS, where add-immediate takes a 37631 16-bit signed value, `TARGET_CONST_ANCHOR' is set to `0x8000'. 37632 The default value is zero, which disables this optimization. 37633 37634 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 37635 Return the offset bitwise ored into shifted address to get 37636 corresponding Address Sanitizer shadow memory address. NULL if 37637 Address Sanitizer is not supported by the target. 37638 37639 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 37640 HOST_WIDE_INT VAL) 37641 Validate target specific memory model mask bits. When NULL no 37642 target specific memory model bits are allowed. 37643 37644 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 37645 This value should be set if the result written by 37646 `atomic_test_and_set' is not exactly 1, i.e. the `bool' `true'. 37647 37648 37649File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 37650 3765118 Host Configuration 37652********************* 37653 37654Most details about the machine and system on which the compiler is 37655actually running are detected by the `configure' script. Some things 37656are impossible for `configure' to detect; these are described in two 37657ways, either by macros defined in a file named `xm-MACHINE.h' or by 37658hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable 37659in `config.gcc'. (The intention is that very few hosts will need a 37660header file but nearly every fully supported host will need to override 37661some hooks.) 37662 37663 If you need to define only a few macros, and they have simple 37664definitions, consider using the `xm_defines' variable in your 37665`config.gcc' entry instead of creating a host configuration header. 37666*Note System Config::. 37667 37668* Menu: 37669 37670* Host Common:: Things every host probably needs implemented. 37671* Filesystem:: Your host can't have the letter `a' in filenames? 37672* Host Misc:: Rare configuration options for hosts. 37673 37674 37675File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 37676 3767718.1 Host Common 37678================ 37679 37680Some things are just not portable, even between similar operating 37681systems, and are too difficult for autoconf to detect. They get 37682implemented using hook functions in the file specified by the 37683HOST_HOOK_OBJ variable in `config.gcc'. 37684 37685 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 37686 This host hook is used to set up handling for extra signals. The 37687 most common thing to do in this hook is to detect stack overflow. 37688 37689 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 37690 FD) 37691 This host hook returns the address of some space that is likely to 37692 be free in some subsequent invocation of the compiler. We intend 37693 to load the PCH data at this address such that the data need not 37694 be relocated. The area should be able to hold SIZE bytes. If the 37695 host uses `mmap', FD is an open file descriptor that can be used 37696 for probing. 37697 37698 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, 37699 size_t SIZE, int FD, size_t OFFSET) 37700 This host hook is called when a PCH file is about to be loaded. 37701 We want to load SIZE bytes from FD at OFFSET into memory at 37702 ADDRESS. The given address will be the result of a previous 37703 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we 37704 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory 37705 is allocated but the data is not loaded. Return 1 if the hook has 37706 performed everything. 37707 37708 If the implementation uses reserved address space, free any 37709 reserved space beyond SIZE, regardless of the return value. If no 37710 PCH will be loaded, this hook may be called with SIZE zero, in 37711 which case all reserved address space should be freed. 37712 37713 Do not try to handle values of ADDRESS that could not have been 37714 returned by this executable; just return -1. Such values usually 37715 indicate an out-of-date PCH file (built by some other GCC 37716 executable), and such a PCH file won't work. 37717 37718 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 37719 This host hook returns the alignment required for allocating 37720 virtual memory. Usually this is the same as getpagesize, but on 37721 some hosts the alignment for reserving memory differs from the 37722 pagesize for committing memory. 37723 37724 37725File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 37726 3772718.2 Host Filesystem 37728==================== 37729 37730GCC needs to know a number of things about the semantics of the host 37731machine's filesystem. Filesystems with Unix and MS-DOS semantics are 37732automatically detected. For other systems, you can define the 37733following macros in `xm-MACHINE.h'. 37734 37735`HAVE_DOS_BASED_FILE_SYSTEM' 37736 This macro is automatically defined by `system.h' if the host file 37737 system obeys the semantics defined by MS-DOS instead of Unix. DOS 37738 file systems are case insensitive, file specifications may begin 37739 with a drive letter, and both forward slash and backslash (`/' and 37740 `\') are directory separators. 37741 37742`DIR_SEPARATOR' 37743`DIR_SEPARATOR_2' 37744 If defined, these macros expand to character constants specifying 37745 separators for directory names within a file specification. 37746 `system.h' will automatically give them appropriate values on Unix 37747 and MS-DOS file systems. If your file system is neither of these, 37748 define one or both appropriately in `xm-MACHINE.h'. 37749 37750 However, operating systems like VMS, where constructing a pathname 37751 is more complicated than just stringing together directory names 37752 separated by a special character, should not define either of these 37753 macros. 37754 37755`PATH_SEPARATOR' 37756 If defined, this macro should expand to a character constant 37757 specifying the separator for elements of search paths. The default 37758 value is a colon (`:'). DOS-based systems usually, but not 37759 always, use semicolon (`;'). 37760 37761`VMS' 37762 Define this macro if the host system is VMS. 37763 37764`HOST_OBJECT_SUFFIX' 37765 Define this macro to be a C string representing the suffix for 37766 object files on your host machine. If you do not define this 37767 macro, GCC will use `.o' as the suffix for object files. 37768 37769`HOST_EXECUTABLE_SUFFIX' 37770 Define this macro to be a C string representing the suffix for 37771 executable files on your host machine. If you do not define this 37772 macro, GCC will use the null string as the suffix for executable 37773 files. 37774 37775`HOST_BIT_BUCKET' 37776 A pathname defined by the host operating system, which can be 37777 opened as a file and written to, but all the information written 37778 is discarded. This is commonly known as a "bit bucket" or "null 37779 device". If you do not define this macro, GCC will use 37780 `/dev/null' as the bit bucket. If the host does not support a bit 37781 bucket, define this macro to an invalid filename. 37782 37783`UPDATE_PATH_HOST_CANONICALIZE (PATH)' 37784 If defined, a C statement (sans semicolon) that performs 37785 host-dependent canonicalization when a path used in a compilation 37786 driver or preprocessor is canonicalized. PATH is a malloc-ed path 37787 to be canonicalized. If the C statement does canonicalize PATH 37788 into a different buffer, the old path should be freed and the new 37789 buffer should have been allocated with malloc. 37790 37791`DUMPFILE_FORMAT' 37792 Define this macro to be a C string representing the format to use 37793 for constructing the index part of debugging dump file names. The 37794 resultant string must fit in fifteen bytes. The full filename 37795 will be the concatenation of: the prefix of the assembler file 37796 name, the string resulting from applying this format to an index 37797 number, and a string unique to each dump file kind, e.g. `rtl'. 37798 37799 If you do not define this macro, GCC will use `.%02d.'. You should 37800 define this macro if using the default will create an invalid file 37801 name. 37802 37803`DELETE_IF_ORDINARY' 37804 Define this macro to be a C statement (sans semicolon) that 37805 performs host-dependent removal of ordinary temp files in the 37806 compilation driver. 37807 37808 If you do not define this macro, GCC will use the default version. 37809 You should define this macro if the default version does not 37810 reliably remove the temp file as, for example, on VMS which allows 37811 multiple versions of a file. 37812 37813`HOST_LACKS_INODE_NUMBERS' 37814 Define this macro if the host filesystem does not report 37815 meaningful inode numbers in struct stat. 37816 37817 37818File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 37819 3782018.3 Host Misc 37821============== 37822 37823`FATAL_EXIT_CODE' 37824 A C expression for the status code to be returned when the compiler 37825 exits after serious errors. The default is the system-provided 37826 macro `EXIT_FAILURE', or `1' if the system doesn't define that 37827 macro. Define this macro only if these defaults are incorrect. 37828 37829`SUCCESS_EXIT_CODE' 37830 A C expression for the status code to be returned when the compiler 37831 exits without serious errors. (Warnings are not serious errors.) 37832 The default is the system-provided macro `EXIT_SUCCESS', or `0' if 37833 the system doesn't define that macro. Define this macro only if 37834 these defaults are incorrect. 37835 37836`USE_C_ALLOCA' 37837 Define this macro if GCC should use the C implementation of 37838 `alloca' provided by `libiberty.a'. This only affects how some 37839 parts of the compiler itself allocate memory. It does not change 37840 code generation. 37841 37842 When GCC is built with a compiler other than itself, the C `alloca' 37843 is always used. This is because most other implementations have 37844 serious bugs. You should define this macro only on a system where 37845 no stack-based `alloca' can possibly work. For instance, if a 37846 system has a small limit on the size of the stack, GCC's builtin 37847 `alloca' will not work reliably. 37848 37849`COLLECT2_HOST_INITIALIZATION' 37850 If defined, a C statement (sans semicolon) that performs 37851 host-dependent initialization when `collect2' is being initialized. 37852 37853`GCC_DRIVER_HOST_INITIALIZATION' 37854 If defined, a C statement (sans semicolon) that performs 37855 host-dependent initialization when a compilation driver is being 37856 initialized. 37857 37858`HOST_LONG_LONG_FORMAT' 37859 If defined, the string used to indicate an argument of type `long 37860 long' to functions like `printf'. The default value is `"ll"'. 37861 37862`HOST_LONG_FORMAT' 37863 If defined, the string used to indicate an argument of type `long' 37864 to functions like `printf'. The default value is `"l"'. 37865 37866`HOST_PTR_PRINTF' 37867 If defined, the string used to indicate an argument of type `void 37868 *' to functions like `printf'. The default value is `"%p"'. 37869 37870 In addition, if `configure' generates an incorrect definition of any 37871of the macros in `auto-host.h', you can override that definition in a 37872host configuration header. If you need to do this, first see if it is 37873possible to fix `configure'. 37874 37875 37876File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 37877 3787819 Makefile Fragments 37879********************* 37880 37881When you configure GCC using the `configure' script, it will construct 37882the file `Makefile' from the template file `Makefile.in'. When it does 37883this, it can incorporate makefile fragments from the `config' 37884directory. These are used to set Makefile parameters that are not 37885amenable to being calculated by autoconf. The list of fragments to 37886incorporate is set by `config.gcc' (and occasionally `config.build' and 37887`config.host'); *Note System Config::. 37888 37889 Fragments are named either `t-TARGET' or `x-HOST', depending on 37890whether they are relevant to configuring GCC to produce code for a 37891particular target, or to configuring GCC to run on a particular host. 37892Here TARGET and HOST are mnemonics which usually have some relationship 37893to the canonical system name, but no formal connection. 37894 37895 If these files do not exist, it means nothing needs to be added for a 37896given target or host. Most targets need a few `t-TARGET' fragments, 37897but needing `x-HOST' fragments is rare. 37898 37899* Menu: 37900 37901* Target Fragment:: Writing `t-TARGET' files. 37902* Host Fragment:: Writing `x-HOST' files. 37903 37904 37905File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 37906 3790719.1 Target Makefile Fragments 37908============================== 37909 37910Target makefile fragments can set these Makefile variables. 37911 37912`LIBGCC2_CFLAGS' 37913 Compiler flags to use when compiling `libgcc2.c'. 37914 37915`LIB2FUNCS_EXTRA' 37916 A list of source file names to be compiled or assembled and 37917 inserted into `libgcc.a'. 37918 37919`CRTSTUFF_T_CFLAGS' 37920 Special flags used when compiling `crtstuff.c'. *Note 37921 Initialization::. 37922 37923`CRTSTUFF_T_CFLAGS_S' 37924 Special flags used when compiling `crtstuff.c' for shared linking. 37925 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. 37926 *Note Initialization::. 37927 37928`MULTILIB_OPTIONS' 37929 For some targets, invoking GCC in different ways produces objects 37930 that can not be linked together. For example, for some targets GCC 37931 produces both big and little endian code. For these targets, you 37932 must arrange for multiple versions of `libgcc.a' to be compiled, 37933 one for each set of incompatible options. When GCC invokes the 37934 linker, it arranges to link in the right version of `libgcc.a', 37935 based on the command line options used. 37936 37937 The `MULTILIB_OPTIONS' macro lists the set of options for which 37938 special versions of `libgcc.a' must be built. Write options that 37939 are mutually incompatible side by side, separated by a slash. 37940 Write options that may be used together separated by a space. The 37941 build procedure will build all combinations of compatible options. 37942 37943 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 37944 msoft-float', `Makefile' will build special versions of `libgcc.a' 37945 using the following sets of options: `-m68000', `-m68020', 37946 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. 37947 37948`MULTILIB_DIRNAMES' 37949 If `MULTILIB_OPTIONS' is used, this variable specifies the 37950 directory names that should be used to hold the various libraries. 37951 Write one element in `MULTILIB_DIRNAMES' for each element in 37952 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the 37953 default value will be `MULTILIB_OPTIONS', with all slashes treated 37954 as spaces. 37955 37956 `MULTILIB_DIRNAMES' describes the multilib directories using GCC 37957 conventions and is applied to directories that are part of the GCC 37958 installation. When multilib-enabled, the compiler will add a 37959 subdirectory of the form PREFIX/MULTILIB before each directory in 37960 the search path for libraries and crt files. 37961 37962 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 37963 msoft-float', then the default value of `MULTILIB_DIRNAMES' is 37964 `m68000 m68020 msoft-float'. You may specify a different value if 37965 you desire a different set of directory names. 37966 37967`MULTILIB_MATCHES' 37968 Sometimes the same option may be written in two different ways. 37969 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know 37970 about any synonyms. In that case, set `MULTILIB_MATCHES' to a 37971 list of items of the form `option=option' to describe all relevant 37972 synonyms. For example, `m68000=mc68000 m68020=mc68020'. 37973 37974`MULTILIB_EXCEPTIONS' 37975 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being 37976 specified, there are combinations that should not be built. In 37977 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch 37978 exceptions in shell case syntax that should not be built. 37979 37980 For example the ARM processor cannot execute both hardware floating 37981 point instructions and the reduced size THUMB instructions at the 37982 same time, so there is no need to build libraries with both of 37983 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: 37984 *mthumb/*mhard-float* 37985 37986`MULTILIB_REQUIRED' 37987 Sometimes when there are only a few combinations are required, it 37988 would be a big effort to come up with a `MULTILIB_EXCEPTIONS' list 37989 to cover all undesired ones. In such a case, just listing all the 37990 required combinations in `MULTILIB_REQUIRED' would be more 37991 straightforward. 37992 37993 The way to specify the entries in `MULTILIB_REQUIRED' is same with 37994 the way used for `MULTILIB_EXCEPTIONS', only this time what are 37995 required will be specified. Suppose there are multiple sets of 37996 `MULTILIB_OPTIONS' and only two combinations are required, one for 37997 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 37998 the `MULTILIB_REQUIRED' can be set to: 37999 `MULTILIB_REQUIRED' = mthumb/march=armv7-m 38000 `MULTILIB_REQUIRED' += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 38001 38002 The `MULTILIB_REQUIRED' can be used together with 38003 `MULTILIB_EXCEPTIONS'. The option combinations generated from 38004 `MULTILIB_OPTIONS' will be filtered by `MULTILIB_EXCEPTIONS' and 38005 then by `MULTILIB_REQUIRED'. 38006 38007`MULTILIB_REUSE' 38008 Sometimes it is desirable to reuse one existing multilib for 38009 different sets of options. Such kind of reuse can minimize the 38010 number of multilib variants. And for some targets it is better to 38011 reuse an existing multilib than to fall back to default multilib 38012 when there is no corresponding multilib. This can be done by 38013 adding reuse rules to `MULTILIB_REUSE'. 38014 38015 A reuse rule is comprised of two parts connected by equality sign. 38016 The left part is option set used to build multilib and the right 38017 part is option set that will reuse this multilib. The order of 38018 options in the left part matters and should be same with those 38019 specified in `MULTILIB_REQUIRED' or aligned with order in 38020 `MULTILIB_OPTIONS'. There is no such limitation for options in 38021 right part as we don't build multilib from them. But the equality 38022 sign in both parts should be replaced with period. 38023 38024 The `MULTILIB_REUSE' is different from `MULTILIB_MATCHES' in that 38025 it sets up relations between two option sets rather than two 38026 options. Here is an example to demo how we reuse libraries built 38027 in Thumb mode for applications built in ARM mode: 38028 `MULTILIB_REUSE' = mthumb/march.armv7-r=marm/march.armv7-r 38029 38030 Before the advent of `MULTILIB_REUSE', GCC select multilib by 38031 comparing command line options with options used to build 38032 multilib. The `MULTILIB_REUSE' is complementary to that way. 38033 Only when the original comparison matches nothing it will work to 38034 see if it is OK to reuse some existing multilib. 38035 38036`MULTILIB_EXTRA_OPTS' 38037 Sometimes it is desirable that when building multiple versions of 38038 `libgcc.a' certain options should always be passed on to the 38039 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list 38040 of options to be used for all builds. If you set this, you should 38041 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. 38042 38043`MULTILIB_OSDIRNAMES' 38044 If `MULTILIB_OPTIONS' is used, this variable specifies a list of 38045 subdirectory names, that are used to modify the search path 38046 depending on the chosen multilib. Unlike `MULTILIB_DIRNAMES', 38047 `MULTILIB_OSDIRNAMES' describes the multilib directories using 38048 operating systems conventions, and is applied to the directories 38049 such as `lib' or those in the `LIBRARY_PATH' environment variable. 38050 The format is either the same as of `MULTILIB_DIRNAMES', or a set 38051 of mappings. When it is the same as `MULTILIB_DIRNAMES', it 38052 describes the multilib directories using operating system 38053 conventions, rather than GCC conventions. When it is a set of 38054 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 38055 convention and the right gives the equivalent OS defined location. 38056 If the OSDIR part begins with a `!', GCC will not search in the 38057 non-multilib directory and use exclusively the multilib directory. 38058 Otherwise, the compiler will examine the search path for libraries 38059 and crt files twice; the first time it will add MULTILIB to each 38060 directory in the search path, the second it will not. 38061 38062 For configurations that support both multilib and multiarch, 38063 `MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 38064 subsuming `MULTIARCH_DIRNAME'. The multiarch name is appended to 38065 each directory name, separated by a colon (e.g. 38066 `../lib32:i386-linux-gnu'). 38067 38068 Each multiarch subdirectory will be searched before the 38069 corresponding OS multilib directory, for example 38070 `/lib/i386-linux-gnu' before `/lib/../lib32'. The multiarch name 38071 will also be used to modify the system header search path, as 38072 explained for `MULTIARCH_DIRNAME'. 38073 38074`MULTIARCH_DIRNAME' 38075 This variable specifies the multiarch name for configurations that 38076 are multiarch-enabled but not multilibbed configurations. 38077 38078 The multiarch name is used to augment the search path for 38079 libraries, crt files and system header files with additional 38080 locations. The compiler will add a multiarch subdirectory of the 38081 form PREFIX/MULTIARCH before each directory in the library and crt 38082 search path. It will also add two directories 38083 `LOCAL_INCLUDE_DIR'/MULTIARCH and 38084 `NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 38085 path, respectively before `LOCAL_INCLUDE_DIR' and 38086 `NATIVE_SYSTEM_HEADER_DIR'. 38087 38088 `MULTIARCH_DIRNAME' is not used for configurations that support 38089 both multilib and multiarch. In that case, multiarch names are 38090 encoded in `MULTILIB_OSDIRNAMES' instead. 38091 38092 More documentation about multiarch can be found at 38093 `http://wiki.debian.org/Multiarch'. 38094 38095`SPECS' 38096 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since 38097 it does not affect the build of target libraries, at least not the 38098 build of the default multilib. One possible work-around is to use 38099 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if 38100 they had been passed in the compiler driver command line. 38101 However, you don't want to be adding these options after the 38102 toolchain is installed, so you can instead tweak the `specs' file 38103 that will be used during the toolchain build, while you still 38104 install the original, built-in `specs'. The trick is to set 38105 `SPECS' to some other filename (say `specs.install'), that will 38106 then be created out of the built-in specs, and introduce a 38107 `Makefile' rule to generate the `specs' file that's going to be 38108 used at build time out of your `specs.install'. 38109 38110`T_CFLAGS' 38111 These are extra flags to pass to the C compiler. They are used 38112 both when building GCC, and when compiling things with the 38113 just-built GCC. This variable is deprecated and should not be 38114 used. 38115 38116 38117File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 38118 3811919.2 Host Makefile Fragments 38120============================ 38121 38122The use of `x-HOST' fragments is discouraged. You should only use it 38123for makefile dependencies. 38124 38125 38126File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 38127 3812820 `collect2' 38129************* 38130 38131GCC uses a utility called `collect2' on nearly all systems to arrange 38132to call various initialization functions at start time. 38133 38134 The program `collect2' works by linking the program once and looking 38135through the linker output file for symbols with particular names 38136indicating they are constructor functions. If it finds any, it creates 38137a new temporary `.c' file containing a table of them, compiles it, and 38138links the program a second time including that file. 38139 38140 The actual calls to the constructors are carried out by a subroutine 38141called `__main', which is called (automatically) at the beginning of 38142the body of `main' (provided `main' was compiled with GNU CC). Calling 38143`__main' is necessary, even when compiling C code, to allow linking C 38144and C++ object code together. (If you use `-nostdlib', you get an 38145unresolved reference to `__main', since it's defined in the standard 38146GCC library. Include `-lgcc' at the end of your compiler command line 38147to resolve this reference.) 38148 38149 The program `collect2' is installed as `ld' in the directory where the 38150passes of the compiler are installed. When `collect2' needs to find 38151the _real_ `ld', it tries the following file names: 38152 38153 * a hard coded linker file name, if GCC was configured with the 38154 `--with-ld' option. 38155 38156 * `real-ld' in the directories listed in the compiler's search 38157 directories. 38158 38159 * `real-ld' in the directories listed in the environment variable 38160 `PATH'. 38161 38162 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 38163 if specified. 38164 38165 * `ld' in the compiler's search directories, except that `collect2' 38166 will not execute itself recursively. 38167 38168 * `ld' in `PATH'. 38169 38170 "The compiler's search directories" means all the directories where 38171`gcc' searches for passes of the compiler. This includes directories 38172that you specify with `-B'. 38173 38174 Cross-compilers search a little differently: 38175 38176 * `real-ld' in the compiler's search directories. 38177 38178 * `TARGET-real-ld' in `PATH'. 38179 38180 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 38181 if specified. 38182 38183 * `ld' in the compiler's search directories. 38184 38185 * `TARGET-ld' in `PATH'. 38186 38187 `collect2' explicitly avoids running `ld' using the file name under 38188which `collect2' itself was invoked. In fact, it remembers up a list 38189of such names--in case one copy of `collect2' finds another copy (or 38190version) of `collect2' installed as `ld' in a second place in the 38191search path. 38192 38193 `collect2' searches for the utilities `nm' and `strip' using the same 38194algorithm as above for `ld'. 38195 38196 38197File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 38198 3819921 Standard Header File Directories 38200*********************************** 38201 38202`GCC_INCLUDE_DIR' means the same thing for native and cross. It is 38203where GCC stores its private include files, and also where GCC stores 38204the fixed include files. A cross compiled GCC runs `fixincludes' on 38205the header files in `$(tooldir)/include'. (If the cross compilation 38206header files need to be fixed, they must be installed before GCC is 38207built. If the cross compilation header files are already suitable for 38208GCC, nothing special need be done). 38209 38210 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 38211is where `g++' looks first for header files. The C++ library installs 38212only target independent header files in that directory. 38213 38214 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 38215install anything there. It is normally `/usr/local/include'. This is 38216where local additions to a packaged system should place header files. 38217 38218 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 38219install anything there. 38220 38221 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 38222the place for other packages to install header files that GCC will use. 38223For a cross-compiler, this is the equivalent of `/usr/include'. When 38224you build a cross-compiler, `fixincludes' processes any header files in 38225this directory. 38226 38227 38228File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 38229 3823022 Memory Management and Type Information 38231***************************************** 38232 38233GCC uses some fairly sophisticated memory management techniques, which 38234involve determining information about GCC's data structures from GCC's 38235source code and using this information to perform garbage collection and 38236implement precompiled headers. 38237 38238 A full C++ parser would be too complicated for this task, so a limited 38239subset of C++ is interpreted and special markers are used to determine 38240what parts of the source to look at. All `struct', `union' and 38241`template' structure declarations that define data structures that are 38242allocated under control of the garbage collector must be marked. All 38243global variables that hold pointers to garbage-collected memory must 38244also be marked. Finally, all global variables that need to be saved 38245and restored by a precompiled header must be marked. (The precompiled 38246header mechanism can only save static variables if they're scalar. 38247Complex data structures must be allocated in garbage-collected memory 38248to be saved in a precompiled header.) 38249 38250 The full format of a marker is 38251 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 38252 but in most cases no options are needed. The outer double parentheses 38253are still necessary, though: `GTY(())'. Markers can appear: 38254 38255 * In a structure definition, before the open brace; 38256 38257 * In a global variable declaration, after the keyword `static' or 38258 `extern'; and 38259 38260 * In a structure field definition, before the name of the field. 38261 38262 Here are some examples of marking simple data structures and globals. 38263 38264 struct GTY(()) TAG 38265 { 38266 FIELDS... 38267 }; 38268 38269 typedef struct GTY(()) TAG 38270 { 38271 FIELDS... 38272 } *TYPENAME; 38273 38274 static GTY(()) struct TAG *LIST; /* points to GC memory */ 38275 static GTY(()) int COUNTER; /* save counter in a PCH */ 38276 38277 The parser understands simple typedefs such as `typedef struct TAG 38278*NAME;' and `typedef int NAME;'. These don't need to be marked. 38279 38280 Since `gengtype''s understanding of C++ is limited, there are several 38281constructs and declarations that are not supported inside 38282classes/structures marked for automatic GC code generation. The 38283following C++ constructs produce a `gengtype' error on 38284structures/classes marked for automatic GC code generation: 38285 38286 * Type definitions inside classes/structures are not supported. 38287 38288 * Enumerations inside classes/structures are not supported. 38289 38290 If you have a class or structure using any of the above constructs, 38291you need to mark that class as `GTY ((user))' and provide your own 38292marking routines (see section *note User GC:: for details). 38293 38294 It is always valid to include function definitions inside classes. 38295Those are always ignored by `gengtype', as it only cares about data 38296members. 38297 38298* Menu: 38299 38300* GTY Options:: What goes inside a `GTY(())'. 38301* User GC:: Adding user-provided GC marking routines. 38302* GGC Roots:: Making global variables GGC roots. 38303* Files:: How the generated files work. 38304* Invoking the garbage collector:: How to invoke the garbage collector. 38305* Troubleshooting:: When something does not work as expected. 38306 38307 38308File: gccint.info, Node: GTY Options, Next: User GC, Up: Type Information 38309 3831022.1 The Inside of a `GTY(())' 38311============================== 38312 38313Sometimes the C code is not enough to fully describe the type 38314structure. Extra information can be provided with `GTY' options and 38315additional markers. Some options take a parameter, which may be either 38316a string or a type name, depending on the parameter. If an option 38317takes no parameter, it is acceptable either to omit the parameter 38318entirely, or to provide an empty string as a parameter. For example, 38319`GTY ((skip))' and `GTY ((skip ("")))' are equivalent. 38320 38321 When the parameter is a string, often it is a fragment of C code. Four 38322special escapes may be used in these strings, to refer to pieces of the 38323data structure being marked: 38324 38325`%h' 38326 The current structure. 38327 38328`%1' 38329 The structure that immediately contains the current structure. 38330 38331`%0' 38332 The outermost structure that contains the current structure. 38333 38334`%a' 38335 A partial expression of the form `[i1][i2]...' that indexes the 38336 array item currently being marked. 38337 38338 For instance, suppose that you have a structure of the form 38339 struct A { 38340 ... 38341 }; 38342 struct B { 38343 struct A foo[12]; 38344 }; 38345 and `b' is a variable of type `struct B'. When marking `b.foo[11]', 38346`%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to 38347`b', and `%a' would expand to `[11]'. 38348 38349 As in ordinary C, adjacent strings will be concatenated; this is 38350helpful when you have a complicated expression. 38351 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 38352 " ? TYPE_NEXT_VARIANT (&%h.generic)" 38353 " : TREE_CHAIN (&%h.generic)"))) 38354 38355 The available options are: 38356 38357`length ("EXPRESSION")' 38358 There are two places the type machinery will need to be explicitly 38359 told the length of an array of non-atomic objects. The first case 38360 is when a structure ends in a variable-length array, like this: 38361 struct GTY(()) rtvec_def { 38362 int num_elem; /* number of elements */ 38363 rtx GTY ((length ("%h.num_elem"))) elem[1]; 38364 }; 38365 38366 In this case, the `length' option is used to override the specified 38367 array length (which should usually be `1'). The parameter of the 38368 option is a fragment of C code that calculates the length. 38369 38370 The second case is when a structure or a global variable contains a 38371 pointer to an array, like this: 38372 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 38373 In this case, `iter' has been allocated by writing something like 38374 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 38375 and the `collapse' provides the length of the field. 38376 38377 This second use of `length' also works on global variables, like: static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 38378 38379 Note that the `length' option is only meant for use with arrays of 38380 non-atomic objects, that is, objects that contain pointers 38381 pointing to other GTY-managed objects. For other GC-allocated 38382 arrays and strings you should use `atomic'. 38383 38384`skip' 38385 If `skip' is applied to a field, the type machinery will ignore it. 38386 This is somewhat dangerous; the only safe use is in a union when 38387 one field really isn't ever used. 38388 38389`desc ("EXPRESSION")' 38390`tag ("CONSTANT")' 38391`default' 38392 The type machinery needs to be told which field of a `union' is 38393 currently active. This is done by giving each field a constant 38394 `tag' value, and then specifying a discriminator using `desc'. 38395 The value of the expression given by `desc' is compared against 38396 each `tag' value, each of which should be different. If no `tag' 38397 is matched, the field marked with `default' is used if there is 38398 one, otherwise no field in the union will be marked. 38399 38400 In the `desc' option, the "current structure" is the union that it 38401 discriminates. Use `%1' to mean the structure containing it. 38402 There are no escapes available to the `tag' option, since it is a 38403 constant. 38404 38405 For example, 38406 struct GTY(()) tree_binding 38407 { 38408 struct tree_common common; 38409 union tree_binding_u { 38410 tree GTY ((tag ("0"))) scope; 38411 struct cp_binding_level * GTY ((tag ("1"))) level; 38412 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 38413 tree value; 38414 }; 38415 38416 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 38417 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type 38418 mechanism will treat the field `level' as being present and if 0, 38419 will treat the field `scope' as being present. 38420 38421`param_is (TYPE)' 38422`use_param' 38423 Sometimes it's convenient to define some data structure to work on 38424 generic pointers (that is, `PTR') and then use it with a specific 38425 type. `param_is' specifies the real type pointed to, and 38426 `use_param' says where in the generic data structure that type 38427 should be put. 38428 38429 For instance, to have a `htab_t' that points to trees, one would 38430 write the definition of `htab_t' like this: 38431 typedef struct GTY(()) { 38432 ... 38433 void ** GTY ((use_param, ...)) entries; 38434 ... 38435 } htab_t; 38436 and then declare variables like this: 38437 static htab_t GTY ((param_is (union tree_node))) ict; 38438 38439`paramN_is (TYPE)' 38440`use_paramN' 38441 In more complicated cases, the data structure might need to work on 38442 several different types, which might not necessarily all be 38443 pointers. For this, `param1_is' through `param9_is' may be used to 38444 specify the real type of a field identified by `use_param1' through 38445 `use_param9'. 38446 38447`use_params' 38448 When a structure contains another structure that is parameterized, 38449 there's no need to do anything special, the inner structure 38450 inherits the parameters of the outer one. When a structure 38451 contains a pointer to a parameterized structure, the type 38452 machinery won't automatically detect this (it could, it just 38453 doesn't yet), so it's necessary to tell it that the pointed-to 38454 structure should use the same parameters as the outer structure. 38455 This is done by marking the pointer with the `use_params' option. 38456 38457`deletable' 38458 `deletable', when applied to a global variable, indicates that when 38459 garbage collection runs, there's no need to mark anything pointed 38460 to by this variable, it can just be set to `NULL' instead. This 38461 is used to keep a list of free structures around for re-use. 38462 38463`if_marked ("EXPRESSION")' 38464 Suppose you want some kinds of object to be unique, and so you put 38465 them in a hash table. If garbage collection marks the hash table, 38466 these objects will never be freed, even if the last other 38467 reference to them goes away. GGC has special handling to deal 38468 with this: if you use the `if_marked' option on a global hash 38469 table, GGC will call the routine whose name is the parameter to 38470 the option on each hash table entry. If the routine returns 38471 nonzero, the hash table entry will be marked as usual. If the 38472 routine returns zero, the hash table entry will be deleted. 38473 38474 The routine `ggc_marked_p' can be used to determine if an element 38475 has been marked already; in fact, the usual case is to use 38476 `if_marked ("ggc_marked_p")'. 38477 38478`mark_hook ("HOOK-ROUTINE-NAME")' 38479 If provided for a structure or union type, the given 38480 HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine 38481 called when the garbage collector has just marked the data as 38482 reachable. This routine should not change the data, or call any ggc 38483 routine. Its only argument is a pointer to the just marked (const) 38484 structure or union. 38485 38486`maybe_undef' 38487 When applied to a field, `maybe_undef' indicates that it's OK if 38488 the structure that this fields points to is never defined, so long 38489 as this field is always `NULL'. This is used to avoid requiring 38490 backends to define certain optional structures. It doesn't work 38491 with language frontends. 38492 38493`nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 38494 The type machinery expects all pointers to point to the start of an 38495 object. Sometimes for abstraction purposes it's convenient to have 38496 a pointer which points inside an object. So long as it's possible 38497 to convert the original object to and from the pointer, such 38498 pointers can still be used. TYPE is the type of the original 38499 object, the TO EXPRESSION returns the pointer given the original 38500 object, and the FROM EXPRESSION returns the original object given 38501 the pointer. The pointer will be available using the `%h' escape. 38502 38503`chain_next ("EXPRESSION")' 38504`chain_prev ("EXPRESSION")' 38505`chain_circular ("EXPRESSION")' 38506 It's helpful for the type machinery to know if objects are often 38507 chained together in long lists; this lets it generate code that 38508 uses less stack space by iterating along the list instead of 38509 recursing down it. `chain_next' is an expression for the next 38510 item in the list, `chain_prev' is an expression for the previous 38511 item. For singly linked lists, use only `chain_next'; for doubly 38512 linked lists, use both. The machinery requires that taking the 38513 next item of the previous item gives the original item. 38514 `chain_circular' is similar to `chain_next', but can be used for 38515 circular single linked lists. 38516 38517`reorder ("FUNCTION NAME")' 38518 Some data structures depend on the relative ordering of pointers. 38519 If the precompiled header machinery needs to change that ordering, 38520 it will call the function referenced by the `reorder' option, 38521 before changing the pointers in the object that's pointed to by 38522 the field the option applies to. The function must take four 38523 arguments, with the signature 38524 `void *, void *, gt_pointer_operator, void *'. The first 38525 parameter is a pointer to the structure that contains the object 38526 being updated, or the object itself if there is no containing 38527 structure. The second parameter is a cookie that should be 38528 ignored. The third parameter is a routine that, given a pointer, 38529 will update it to its correct new value. The fourth parameter is 38530 a cookie that must be passed to the second parameter. 38531 38532 PCH cannot handle data structures that depend on the absolute 38533 values of pointers. `reorder' functions can be expensive. When 38534 possible, it is better to depend on properties of the data, like 38535 an ID number or the hash of a string instead. 38536 38537`variable_size' 38538 The type machinery expects the types to be of constant size. When 38539 this is not true, for example, with structs that have array fields 38540 or unions, the type machinery cannot tell how many bytes need to 38541 be allocated at each allocation. The `variable_size' is used to 38542 mark such types. The type machinery then provides allocators that 38543 take a parameter indicating an exact size of object being 38544 allocated. Note that the size must be provided in bytes whereas 38545 the `length' option works with array lengths in number of elements. 38546 38547 For example, 38548 struct GTY((variable_size)) sorted_fields_type { 38549 int len; 38550 tree GTY((length ("%h.len"))) elts[1]; 38551 }; 38552 38553 Then the objects of `struct sorted_fields_type' are allocated in GC 38554 memory as follows: 38555 field_vec = ggc_alloc_sorted_fields_type (size); 38556 38557 If FIELD_VEC->ELTS stores N elements, then SIZE could be 38558 calculated as follows: 38559 size_t size = sizeof (struct sorted_fields_type) + n * sizeof (tree); 38560 38561`atomic' 38562 The `atomic' option can only be used with pointers. It informs 38563 the GC machinery that the memory that the pointer points to does 38564 not contain any pointers, and hence it should be treated by the GC 38565 and PCH machinery as an "atomic" block of memory that does not 38566 need to be examined when scanning memory for pointers. In 38567 particular, the machinery will not scan that memory for pointers 38568 to mark them as reachable (when marking pointers for GC) or to 38569 relocate them (when writing a PCH file). 38570 38571 The `atomic' option differs from the `skip' option. `atomic' 38572 keeps the memory under Garbage Collection, but makes the GC ignore 38573 the contents of the memory. `skip' is more drastic in that it 38574 causes the pointer and the memory to be completely ignored by the 38575 Garbage Collector. So, memory marked as `atomic' is automatically 38576 freed when no longer reachable, while memory marked as `skip' is 38577 not. 38578 38579 The `atomic' option must be used with great care, because all 38580 sorts of problem can occur if used incorrectly, that is, if the 38581 memory the pointer points to does actually contain a pointer. 38582 38583 Here is an example of how to use it: 38584 struct GTY(()) my_struct { 38585 int number_of_elements; 38586 unsigned int * GTY ((atomic)) elements; 38587 }; 38588 In this case, `elements' is a pointer under GC, and the memory it 38589 points to needs to be allocated using the Garbage Collector, and 38590 will be freed automatically by the Garbage Collector when it is no 38591 longer referenced. But the memory that the pointer points to is 38592 an array of `unsigned int' elements, and the GC must not try to 38593 scan it to find pointers to mark or relocate, which is why it is 38594 marked with the `atomic' option. 38595 38596 Note that, currently, global variables can not be marked with 38597 `atomic'; only fields of a struct can. This is a known 38598 limitation. It would be useful to be able to mark global pointers 38599 with `atomic' to make the PCH machinery aware of them so that they 38600 are saved and restored correctly to PCH files. 38601 38602`special ("NAME")' 38603 The `special' option is used to mark types that have to be dealt 38604 with by special case machinery. The parameter is the name of the 38605 special case. See `gengtype.c' for further details. Avoid adding 38606 new special cases unless there is no other alternative. 38607 38608`user' 38609 The `user' option indicates that the code to mark structure fields 38610 is completely handled by user-provided routines. See section 38611 *note User GC:: for details on what functions need to be provided. 38612 38613 38614File: gccint.info, Node: User GC, Next: GGC Roots, Prev: GTY Options, Up: Type Information 38615 3861622.2 Support for user-provided GC marking routines 38617================================================== 38618 38619The garbage collector supports types for which no automatic marking 38620code is generated. For these types, the user is required to provide 38621three functions: one to act as a marker for garbage collection, and two 38622functions to act as marker and pointer walker for pre-compiled headers. 38623 38624 Given a structure `struct GTY((user)) my_struct', the following 38625functions should be defined to mark `my_struct': 38626 38627 void gt_ggc_mx (my_struct *p) 38628 { 38629 /* This marks field 'fld'. */ 38630 gt_ggc_mx (p->fld); 38631 } 38632 38633 void gt_pch_nx (my_struct *p) 38634 { 38635 /* This marks field 'fld'. */ 38636 gt_pch_nx (tp->fld); 38637 } 38638 38639 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 38640 { 38641 /* For every field 'fld', call the given pointer operator. */ 38642 op (&(tp->fld), cookie); 38643 } 38644 38645 In general, each marker `M' should call `M' for every pointer field in 38646the structure. Fields that are not allocated in GC or are not pointers 38647must be ignored. 38648 38649 For embedded lists (e.g., structures with a `next' or `prev' pointer), 38650the marker must follow the chain and mark every element in it. 38651 38652 Note that the rules for the pointer walker `gt_pch_nx (my_struct *, 38653gt_pointer_operator, void *)' are slightly different. In this case, 38654the operation `op' must be applied to the _address_ of every pointer 38655field. 38656 3865722.2.1 User-provided marking routines for template types 38658-------------------------------------------------------- 38659 38660When a template type `TP' is marked with `GTY', all instances of that 38661type are considered user-provided types. This means that the 38662individual instances of `TP' do not need to be marked with `GTY'. The 38663user needs to provide template functions to mark all the fields of the 38664type. 38665 38666 The following code snippets represent all the functions that need to 38667be provided. Note that type `TP' may reference to more than one type. 38668In these snippets, there is only one type `T', but there could be more. 38669 38670 template<typename T> 38671 void gt_ggc_mx (TP<T> *tp) 38672 { 38673 extern void gt_ggc_mx (T&); 38674 38675 /* This marks field 'fld' of type 'T'. */ 38676 gt_ggc_mx (tp->fld); 38677 } 38678 38679 template<typename T> 38680 void gt_pch_nx (TP<T> *tp) 38681 { 38682 extern void gt_pch_nx (T&); 38683 38684 /* This marks field 'fld' of type 'T'. */ 38685 gt_pch_nx (tp->fld); 38686 } 38687 38688 template<typename T> 38689 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 38690 { 38691 /* For every field 'fld' of 'tp' with type 'T *', call the given 38692 pointer operator. */ 38693 op (&(tp->fld), cookie); 38694 } 38695 38696 template<typename T> 38697 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 38698 { 38699 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 38700 38701 /* For every field 'fld' of 'tp' with type 'T', call the pointer 38702 walker for all the fields of T. */ 38703 gt_pch_nx (&(tp->fld), op, cookie); 38704 } 38705 38706 Support for user-defined types is currently limited. The following 38707restrictions apply: 38708 38709 1. Type `TP' and all the argument types `T' must be marked with `GTY'. 38710 38711 2. Type `TP' can only have type names in its argument list. 38712 38713 3. The pointer walker functions are different for `TP<T>' and `TP<T 38714 *>'. In the case of `TP<T>', references to `T' must be handled by 38715 calling `gt_pch_nx' (which will, in turn, walk all the pointers 38716 inside fields of `T'). In the case of `TP<T *>', references to `T 38717 *' must be handled by calling the `op' function on the address of 38718 the pointer (see the code snippets above). 38719 38720 38721File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 38722 3872322.3 Marking Roots for the Garbage Collector 38724============================================ 38725 38726In addition to keeping track of types, the type machinery also locates 38727the global variables ("roots") that the garbage collector starts at. 38728Roots must be declared using one of the following syntaxes: 38729 38730 * `extern GTY(([OPTIONS])) TYPE NAME;' 38731 38732 * `static GTY(([OPTIONS])) TYPE NAME;' 38733 The syntax 38734 * `GTY(([OPTIONS])) TYPE NAME;' 38735 is _not_ accepted. There should be an `extern' declaration of such a 38736variable in a header somewhere--mark that, not the definition. Or, if 38737the variable is only used in one file, make it `static'. 38738 38739 38740File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 38741 3874222.4 Source Files Containing Type Information 38743============================================= 38744 38745Whenever you add `GTY' markers to a source file that previously had 38746none, or create a new source file containing `GTY' markers, there are 38747three things you need to do: 38748 38749 1. You need to add the file to the list of source files the type 38750 machinery scans. There are four cases: 38751 38752 a. For a back-end file, this is usually done automatically; if 38753 not, you should add it to `target_gtfiles' in the appropriate 38754 port's entries in `config.gcc'. 38755 38756 b. For files shared by all front ends, add the filename to the 38757 `GTFILES' variable in `Makefile.in'. 38758 38759 c. For files that are part of one front end, add the filename to 38760 the `gtfiles' variable defined in the appropriate 38761 `config-lang.in'. Headers should appear before non-headers 38762 in this list. 38763 38764 d. For files that are part of some but not all front ends, add 38765 the filename to the `gtfiles' variable of _all_ the front ends 38766 that use it. 38767 38768 2. If the file was a header file, you'll need to check that it's 38769 included in the right place to be visible to the generated files. 38770 For a back-end header file, this should be done automatically. 38771 For a front-end header file, it needs to be included by the same 38772 file that includes `gtype-LANG.h'. For other header files, it 38773 needs to be included in `gtype-desc.c', which is a generated file, 38774 so add it to `ifiles' in `open_base_file' in `gengtype.c'. 38775 38776 For source files that aren't header files, the machinery will 38777 generate a header file that should be included in the source file 38778 you just changed. The file will be called `gt-PATH.h' where PATH 38779 is the pathname relative to the `gcc' directory with slashes 38780 replaced by -, so for example the header file to be included in 38781 `cp/parser.c' is called `gt-cp-parser.c'. The generated header 38782 file should be included after everything else in the source file. 38783 Don't forget to mention this file as a dependency in the 38784 `Makefile'! 38785 38786 38787 For language frontends, there is another file that needs to be included 38788somewhere. It will be called `gtype-LANG.h', where LANG is the name of 38789the subdirectory the language is contained in. 38790 38791 Plugins can add additional root tables. Run the `gengtype' utility in 38792plugin mode as `gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 38793with your plugin files PLUGIN*.C using `GTY' to generate the 38794PLUGINOUT.H file. The GCC build tree is needed to be present in that 38795mode. 38796 38797 38798File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 38799 3880022.5 How to invoke the garbage collector 38801======================================== 38802 38803The GCC garbage collector GGC is only invoked explicitly. In contrast 38804with many other garbage collectors, it is not implicitly invoked by 38805allocation routines when a lot of memory has been consumed. So the only 38806way to have GGC reclaim storage is to call the `ggc_collect' function 38807explicitly. This call is an expensive operation, as it may have to 38808scan the entire heap. Beware that local variables (on the GCC call 38809stack) are not followed by such an invocation (as many other garbage 38810collectors do): you should reference all your data from static or 38811external `GTY'-ed variables, and it is advised to call `ggc_collect' 38812with a shallow call stack. The GGC is an exact mark and sweep garbage 38813collector (so it does not scan the call stack for pointers). In 38814practice GCC passes don't often call `ggc_collect' themselves, because 38815it is called by the pass manager between passes. 38816 38817 At the time of the `ggc_collect' call all pointers in the GC-marked 38818structures must be valid or `NULL'. In practice this means that there 38819should not be uninitialized pointer fields in the structures even if 38820your code never reads or writes those fields at a particular instance. 38821One way to ensure this is to use cleared versions of allocators unless 38822all the fields are initialized manually immediately after allocation. 38823 38824 38825File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 38826 3882722.6 Troubleshooting the garbage collector 38828========================================== 38829 38830With the current garbage collector implementation, most issues should 38831show up as GCC compilation errors. Some of the most commonly 38832encountered issues are described below. 38833 38834 * Gengtype does not produce allocators for a `GTY'-marked type. 38835 Gengtype checks if there is at least one possible path from GC 38836 roots to at least one instance of each type before outputting 38837 allocators. If there is no such path, the `GTY' markers will be 38838 ignored and no allocators will be output. Solve this by making 38839 sure that there exists at least one such path. If creating it is 38840 unfeasible or raises a "code smell", consider if you really must 38841 use GC for allocating such type. 38842 38843 * Link-time errors about undefined `gt_ggc_r_foo_bar' and 38844 similarly-named symbols. Check if your `foo_bar' source file has 38845 `#include "gt-foo_bar.h"' as its very last line. 38846 38847 38848 38849File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 38850 3885123 Plugins 38852********** 38853 38854GCC plugin is a loadable module that provides extra features to the 38855compiler, which they can further pass around as a shareable module. 38856 38857 GCC plugins provide developers with a rich subset of the GCC API to 38858allow them to extend GCC as they see fit. Whether it is writing an 38859additional optimization pass, transforming code, or analyzing 38860information, plugins can be quite useful. 38861 38862* Menu: 38863 38864* Plugins loading:: How can we load plugins. 38865* Plugin API:: The APIs for plugins. 38866* Plugins pass:: How a plugin interact with the pass manager. 38867* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 38868* Plugins description:: Giving information about a plugin itself. 38869* Plugins attr:: Registering custom attributes or pragmas. 38870* Plugins recording:: Recording information about pass execution. 38871* Plugins gate:: Controlling which passes are being run. 38872* Plugins tracking:: Keeping track of available passes. 38873* Plugins building:: How can we build a plugin. 38874 38875 38876File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 38877 3887823.1 Loading Plugins 38879==================== 38880 38881Plugins are supported on platforms that support `-ldl -rdynamic'. They 38882are loaded by the compiler using `dlopen' and invoked at pre-determined 38883locations in the compilation process. 38884 38885 Plugins are loaded with 38886 38887 `-fplugin=/path/to/NAME.so' `-fplugin-arg-NAME-KEY1[=VALUE1]' 38888 38889 The plugin arguments are parsed by GCC and passed to respective 38890plugins as key-value pairs. Multiple plugins can be invoked by 38891specifying multiple `-fplugin' arguments. 38892 38893 A plugin can be simply given by its short name (no dots or slashes). 38894When simply passing `-fplugin=NAME', the plugin is loaded from the 38895`plugin' directory, so `-fplugin=NAME' is the same as `-fplugin=`gcc 38896-print-file-name=plugin`/NAME.so', using backquote shell syntax to 38897query the `plugin' directory. 38898 38899 38900File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 38901 3890223.2 Plugin API 38903=============== 38904 38905Plugins are activated by the compiler at specific events as defined in 38906`gcc-plugin.h'. For each event of interest, the plugin should call 38907`register_callback' specifying the name of the event and address of the 38908callback function that will handle that event. 38909 38910 The header `gcc-plugin.h' must be the first gcc header to be included. 38911 3891223.2.1 Plugin license check 38913--------------------------- 38914 38915Every plugin should define the global symbol `plugin_is_GPL_compatible' 38916to assert that it has been licensed under a GPL-compatible license. If 38917this symbol does not exist, the compiler will emit a fatal error and 38918exit with the error message: 38919 38920 fatal error: plugin NAME is not licensed under a GPL-compatible license 38921 NAME: undefined symbol: plugin_is_GPL_compatible 38922 compilation terminated 38923 38924 The declared type of the symbol should be int, to match a forward 38925declaration in `gcc-plugin.h' that suppresses C++ mangling. It does 38926not need to be in any allocated section, though. The compiler merely 38927asserts that the symbol exists in the global scope. Something like 38928this is enough: 38929 38930 int plugin_is_GPL_compatible; 38931 3893223.2.2 Plugin initialization 38933---------------------------- 38934 38935Every plugin should export a function called `plugin_init' that is 38936called right after the plugin is loaded. This function is responsible 38937for registering all the callbacks required by the plugin and do any 38938other required initialization. 38939 38940 This function is called from `compile_file' right before invoking the 38941parser. The arguments to `plugin_init' are: 38942 38943 * `plugin_info': Plugin invocation information. 38944 38945 * `version': GCC version. 38946 38947 The `plugin_info' struct is defined as follows: 38948 38949 struct plugin_name_args 38950 { 38951 char *base_name; /* Short name of the plugin 38952 (filename without .so suffix). */ 38953 const char *full_name; /* Path to the plugin as specified with 38954 -fplugin=. */ 38955 int argc; /* Number of arguments specified with 38956 -fplugin-arg-.... */ 38957 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 38958 const char *version; /* Version string provided by plugin. */ 38959 const char *help; /* Help string provided by plugin. */ 38960 } 38961 38962 If initialization fails, `plugin_init' must return a non-zero value. 38963Otherwise, it should return 0. 38964 38965 The version of the GCC compiler loading the plugin is described by the 38966following structure: 38967 38968 struct plugin_gcc_version 38969 { 38970 const char *basever; 38971 const char *datestamp; 38972 const char *devphase; 38973 const char *revision; 38974 const char *configuration_arguments; 38975 }; 38976 38977 The function `plugin_default_version_check' takes two pointers to such 38978structure and compare them field by field. It can be used by the 38979plugin's `plugin_init' function. 38980 38981 The version of GCC used to compile the plugin can be found in the 38982symbol `gcc_version' defined in the header `plugin-version.h'. The 38983recommended version check to perform looks like 38984 38985 #include "plugin-version.h" 38986 ... 38987 38988 int 38989 plugin_init (struct plugin_name_args *plugin_info, 38990 struct plugin_gcc_version *version) 38991 { 38992 if (!plugin_default_version_check (version, &gcc_version)) 38993 return 1; 38994 38995 } 38996 38997 but you can also check the individual fields if you want a less strict 38998check. 38999 3900023.2.3 Plugin callbacks 39001----------------------- 39002 39003Callback functions have the following prototype: 39004 39005 /* The prototype for a plugin callback function. 39006 gcc_data - event-specific data provided by GCC 39007 user_data - plugin-specific data provided by the plug-in. */ 39008 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 39009 39010 Callbacks can be invoked at the following pre-determined events: 39011 39012 enum plugin_event 39013 { 39014 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 39015 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 39016 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 39017 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 39018 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 39019 PLUGIN_FINISH, /* Called before GCC exits. */ 39020 PLUGIN_INFO, /* Information about the plugin. */ 39021 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 39022 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 39023 PLUGIN_GGC_END, /* Called at end of GGC. */ 39024 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 39025 PLUGIN_REGISTER_GGC_CACHES, /* Register an extra GGC cache table. */ 39026 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 39027 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 39028 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 39029 /* Called before first pass from all_passes. */ 39030 PLUGIN_ALL_PASSES_START, 39031 /* Called after last pass from all_passes. */ 39032 PLUGIN_ALL_PASSES_END, 39033 /* Called before first ipa pass. */ 39034 PLUGIN_ALL_IPA_PASSES_START, 39035 /* Called after last ipa pass. */ 39036 PLUGIN_ALL_IPA_PASSES_END, 39037 /* Allows to override pass gate decision for current_pass. */ 39038 PLUGIN_OVERRIDE_GATE, 39039 /* Called before executing a pass. */ 39040 PLUGIN_PASS_EXECUTION, 39041 /* Called before executing subpasses of a GIMPLE_PASS in 39042 execute_ipa_pass_list. */ 39043 PLUGIN_EARLY_GIMPLE_PASSES_START, 39044 /* Called after executing subpasses of a GIMPLE_PASS in 39045 execute_ipa_pass_list. */ 39046 PLUGIN_EARLY_GIMPLE_PASSES_END, 39047 /* Called when a pass is first instantiated. */ 39048 PLUGIN_NEW_PASS, 39049 39050 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 39051 array. */ 39052 }; 39053 39054 In addition, plugins can also look up the enumerator of a named event, 39055and / or generate new events dynamically, by calling the function 39056`get_named_event_id'. 39057 39058 To register a callback, the plugin calls `register_callback' with the 39059arguments: 39060 39061 * `char *name': Plugin name. 39062 39063 * `int event': The event code. 39064 39065 * `plugin_callback_func callback': The function that handles `event'. 39066 39067 * `void *user_data': Pointer to plugin-specific data. 39068 39069 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, 39070PLUGIN_REGISTER_GGC_ROOTS and PLUGIN_REGISTER_GGC_CACHES pseudo-events 39071the `callback' should be null, and the `user_data' is specific. 39072 39073 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as 39074data from GCC), plugins may register their own pragmas using functions 39075like `c_register_pragma' or `c_register_pragma_with_expansion'. 39076 39077 39078File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 39079 3908023.3 Interacting with the pass manager 39081====================================== 39082 39083There needs to be a way to add/reorder/remove passes dynamically. This 39084is useful for both analysis plugins (plugging in after a certain pass 39085such as CFG or an IPA pass) and optimization plugins. 39086 39087 Basic support for inserting new passes or replacing existing passes is 39088provided. A plugin registers a new pass with GCC by calling 39089`register_callback' with the `PLUGIN_PASS_MANAGER_SETUP' event and a 39090pointer to a `struct register_pass_info' object defined as follows 39091 39092 enum pass_positioning_ops 39093 { 39094 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 39095 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 39096 PASS_POS_REPLACE // Replace the reference pass. 39097 }; 39098 39099 struct register_pass_info 39100 { 39101 struct opt_pass *pass; /* New pass provided by the plugin. */ 39102 const char *reference_pass_name; /* Name of the reference pass for hooking 39103 up the new pass. */ 39104 int ref_pass_instance_number; /* Insert the pass at the specified 39105 instance number of the reference pass. */ 39106 /* Do it for every instance if it is 0. */ 39107 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 39108 }; 39109 39110 39111 /* Sample plugin code that registers a new pass. */ 39112 int 39113 plugin_init (struct plugin_name_args *plugin_info, 39114 struct plugin_gcc_version *version) 39115 { 39116 struct register_pass_info pass_info; 39117 39118 ... 39119 39120 /* Code to fill in the pass_info object with new pass information. */ 39121 39122 ... 39123 39124 /* Register the new pass. */ 39125 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 39126 39127 ... 39128 } 39129 39130 39131File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 39132 3913323.4 Interacting with the GCC Garbage Collector 39134=============================================== 39135 39136Some plugins may want to be informed when GGC (the GCC Garbage 39137Collector) is running. They can register callbacks for the 39138`PLUGIN_GGC_START' and `PLUGIN_GGC_END' events (for which the callback 39139is called with a null `gcc_data') to be notified of the start or end of 39140the GCC garbage collection. 39141 39142 Some plugins may need to have GGC mark additional data. This can be 39143done by registering a callback (called with a null `gcc_data') for the 39144`PLUGIN_GGC_MARKING' event. Such callbacks can call the `ggc_set_mark' 39145routine, preferably through the `ggc_mark' macro (and conversely, these 39146routines should usually not be used in plugins outside of the 39147`PLUGIN_GGC_MARKING' event). 39148 39149 Some plugins may need to add extra GGC root tables, e.g. to handle 39150their own `GTY'-ed data. This can be done with the 39151`PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 39152extra root table (of type `struct ggc_root_tab*') as `user_data'. 39153Plugins that want to use the `if_marked' hash table option can add the 39154extra GGC cache tables generated by `gengtype' using the 39155`PLUGIN_REGISTER_GGC_CACHES' pseudo-event with a null callback and the 39156extra cache table (of type `struct ggc_cache_tab*') as `user_data'. 39157Running the `gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 39158generates these extra root tables. 39159 39160 You should understand the details of memory management inside GCC 39161before using `PLUGIN_GGC_MARKING', `PLUGIN_REGISTER_GGC_ROOTS' or 39162`PLUGIN_REGISTER_GGC_CACHES'. 39163 39164 39165File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 39166 3916723.5 Giving information about a plugin 39168====================================== 39169 39170A plugin should give some information to the user about itself. This 39171uses the following structure: 39172 39173 struct plugin_info 39174 { 39175 const char *version; 39176 const char *help; 39177 }; 39178 39179 Such a structure is passed as the `user_data' by the plugin's init 39180routine using `register_callback' with the `PLUGIN_INFO' pseudo-event 39181and a null callback. 39182 39183 39184File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 39185 3918623.6 Registering custom attributes or pragmas 39187============================================= 39188 39189For analysis (or other) purposes it is useful to be able to add custom 39190attributes or pragmas. 39191 39192 The `PLUGIN_ATTRIBUTES' callback is called during attribute 39193registration. Use the `register_attribute' function to register custom 39194attributes. 39195 39196 /* Attribute handler callback */ 39197 static tree 39198 handle_user_attribute (tree *node, tree name, tree args, 39199 int flags, bool *no_add_attrs) 39200 { 39201 return NULL_TREE; 39202 } 39203 39204 /* Attribute definition */ 39205 static struct attribute_spec user_attr = 39206 { "user", 1, 1, false, false, false, handle_user_attribute, false }; 39207 39208 /* Plugin callback called during attribute registration. 39209 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 39210 */ 39211 static void 39212 register_attributes (void *event_data, void *data) 39213 { 39214 warning (0, G_("Callback to register attributes")); 39215 register_attribute (&user_attr); 39216 } 39217 39218 The `PLUGIN_PRAGMAS' callback is called during pragmas registration. 39219Use the `c_register_pragma' or `c_register_pragma_with_expansion' 39220functions to register custom pragmas. 39221 39222 /* Plugin callback called during pragmas registration. Registered with 39223 register_callback (plugin_name, PLUGIN_PRAGMAS, 39224 register_my_pragma, NULL); 39225 */ 39226 static void 39227 register_my_pragma (void *event_data, void *data) 39228 { 39229 warning (0, G_("Callback to register pragmas")); 39230 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 39231 } 39232 39233 It is suggested to pass `"GCCPLUGIN"' (or a short name identifying 39234your plugin) as the "space" argument of your pragma. 39235 39236 39237File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 39238 3923923.7 Recording information about pass execution 39240=============================================== 39241 39242The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 39243(the same as current_pass) as `gcc_data' to the callback. You can also 39244inspect cfun to find out about which function this pass is executed for. 39245Note that this event will only be invoked if the gate check (if 39246applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 39247other hooks, like `PLUGIN_ALL_PASSES_START', `PLUGIN_ALL_PASSES_END', 39248`PLUGIN_ALL_IPA_PASSES_START', `PLUGIN_ALL_IPA_PASSES_END', 39249`PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 39250`PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 39251plugin(s) in order to get context for the pass execution. 39252 39253 39254File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 39255 3925623.8 Controlling which passes are being run 39257=========================================== 39258 39259After the original gate function for a pass is called, its result - the 39260gate status - is stored as an integer. Then the event 39261`PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 39262the `gcc_data' parameter to the callback function. A nonzero value of 39263the gate status means that the pass is to be executed. You can both 39264read and write the gate status via the passed pointer. 39265 39266 39267File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 39268 3926923.9 Keeping track of available passes 39270====================================== 39271 39272When your plugin is loaded, you can inspect the various pass lists to 39273determine what passes are available. However, other plugins might add 39274new passes. Also, future changes to GCC might cause generic passes to 39275be added after plugin loading. When a pass is first added to one of 39276the pass lists, the event `PLUGIN_NEW_PASS' is invoked, with the 39277callback parameter `gcc_data' pointing to the new pass. 39278 39279 39280File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 39281 3928223.10 Building GCC plugins 39283========================== 39284 39285If plugins are enabled, GCC installs the headers needed to build a 39286plugin (somewhere in the installation tree, e.g. under `/usr/local'). 39287In particular a `plugin/include' directory is installed, containing all 39288the header files needed to build plugins. 39289 39290 On most systems, you can query this `plugin' directory by invoking 39291`gcc -print-file-name=plugin' (replace if needed `gcc' with the 39292appropriate program path). 39293 39294 Inside plugins, this `plugin' directory name can be queried by calling 39295`default_plugin_dir_name ()'. 39296 39297 Plugins may know, when they are compiled, the GCC version for which 39298`plugin-version.h' is provided. The constant macros 39299`GCCPLUGIN_VERSION_MAJOR', `GCCPLUGIN_VERSION_MINOR', 39300`GCCPLUGIN_VERSION_PATCHLEVEL', `GCCPLUGIN_VERSION' are integer 39301numbers, so a plugin could ensure it is built for GCC 4.7 with 39302 #if GCCPLUGIN_VERSION != 4007 39303 #error this GCC plugin is for GCC 4.7 39304 #endif 39305 39306 The following GNU Makefile excerpt shows how to build a simple plugin: 39307 39308 GCC=gcc 39309 PLUGIN_SOURCE_FILES= plugin1.c plugin2.c 39310 PLUGIN_OBJECT_FILES= $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES)) 39311 GCCPLUGINS_DIR:= $(shell $(GCC) -print-file-name=plugin) 39312 CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -O2 39313 39314 plugin.so: $(PLUGIN_OBJECT_FILES) 39315 $(GCC) -shared $^ -o $@ 39316 39317 A single source file plugin may be built with `gcc -I`gcc 39318-print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o 39319plugin.so', using backquote shell syntax to query the `plugin' 39320directory. 39321 39322 When a plugin needs to use `gengtype', be sure that both `gengtype' 39323and `gtype.state' have the same version as the GCC for which the plugin 39324is built. 39325 39326 39327File: gccint.info, Node: LTO, Next: Funding, Prev: Plugins, Up: Top 39328 3932924 Link Time Optimization 39330************************* 39331 39332Link Time Optimization (LTO) gives GCC the capability of dumping its 39333internal representation (GIMPLE) to disk, so that all the different 39334compilation units that make up a single executable can be optimized as 39335a single module. This expands the scope of inter-procedural 39336optimizations to encompass the whole program (or, rather, everything 39337that is visible at link time). 39338 39339* Menu: 39340 39341* LTO Overview:: Overview of LTO. 39342* LTO object file layout:: LTO file sections in ELF. 39343* IPA:: Using summary information in IPA passes. 39344* WHOPR:: Whole program assumptions, 39345 linker plugin and symbol visibilities. 39346* Internal flags:: Internal flags controlling `lto1'. 39347 39348 39349File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 39350 3935124.1 Design Overview 39352==================== 39353 39354Link time optimization is implemented as a GCC front end for a bytecode 39355representation of GIMPLE that is emitted in special sections of `.o' 39356files. Currently, LTO support is enabled in most ELF-based systems, as 39357well as darwin, cygwin and mingw systems. 39358 39359 Since GIMPLE bytecode is saved alongside final object code, object 39360files generated with LTO support are larger than regular object files. 39361This "fat" object format makes it easy to integrate LTO into existing 39362build systems, as one can, for instance, produce archives of the files. 39363Additionally, one might be able to ship one set of fat objects which 39364could be used both for development and the production of optimized 39365builds. A, perhaps surprising, side effect of this feature is that any 39366mistake in the toolchain that leads to LTO information not being used 39367(e.g. an older `libtool' calling `ld' directly). This is both an 39368advantage, as the system is more robust, and a disadvantage, as the 39369user is not informed that the optimization has been disabled. 39370 39371 The current implementation only produces "fat" objects, effectively 39372doubling compilation time and increasing file sizes up to 5x the 39373original size. This hides the problem that some tools, such as `ar' 39374and `nm', need to understand symbol tables of LTO sections. These 39375tools were extended to use the plugin infrastructure, and with these 39376problems solved, GCC will also support "slim" objects consisting of the 39377intermediate code alone. 39378 39379 At the highest level, LTO splits the compiler in two. The first half 39380(the "writer") produces a streaming representation of all the internal 39381data structures needed to optimize and generate code. This includes 39382declarations, types, the callgraph and the GIMPLE representation of 39383function bodies. 39384 39385 When `-flto' is given during compilation of a source file, the pass 39386manager executes all the passes in `all_lto_gen_passes'. Currently, 39387this phase is composed of two IPA passes: 39388 39389 * `pass_ipa_lto_gimple_out' This pass executes the function 39390 `lto_output' in `lto-streamer-out.c', which traverses the call 39391 graph encoding every reachable declaration, type and function. 39392 This generates a memory representation of all the file sections 39393 described below. 39394 39395 * `pass_ipa_lto_finish_out' This pass executes the function 39396 `produce_asm_for_decls' in `lto-streamer-out.c', which takes the 39397 memory image built in the previous pass and encodes it in the 39398 corresponding ELF file sections. 39399 39400 The second half of LTO support is the "reader". This is implemented 39401as the GCC front end `lto1' in `lto/lto.c'. When `collect2' detects a 39402link set of `.o'/`.a' files with LTO information and the `-flto' is 39403enabled, it invokes `lto1' which reads the set of files and aggregates 39404them into a single translation unit for optimization. The main entry 39405point for the reader is `lto/lto.c':`lto_main'. 39406 3940724.1.1 LTO modes of operation 39408----------------------------- 39409 39410One of the main goals of the GCC link-time infrastructure was to allow 39411effective compilation of large programs. For this reason GCC 39412implements two link-time compilation modes. 39413 39414 1. _LTO mode_, in which the whole program is read into the compiler 39415 at link-time and optimized in a similar way as if it were a single 39416 source-level compilation unit. 39417 39418 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 39419 and/or a distributed compilation environment to quickly link large 39420 applications. WHOPR stands for WHOle Program optimizeR (not to be 39421 confused with the semantics of `-fwhole-program'). It partitions 39422 the aggregated callgraph from many different `.o' files and 39423 distributes the compilation of the sub-graphs to different CPUs. 39424 39425 Note that distributed compilation is not implemented yet, but since 39426 the parallelism is facilitated via generating a `Makefile', it 39427 would be easy to implement. 39428 39429 WHOPR splits LTO into three main stages: 39430 1. Local generation (LGEN) This stage executes in parallel. Every 39431 file in the program is compiled into the intermediate language and 39432 packaged together with the local call-graph and summary 39433 information. This stage is the same for both the LTO and WHOPR 39434 compilation mode. 39435 39436 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 39437 global call-graph is generated, and a global analysis procedure 39438 makes transformation decisions. The global call-graph is 39439 partitioned to facilitate parallel optimization during phase 3. 39440 The results of the WPA stage are stored into new object files 39441 which contain the partitions of program expressed in the 39442 intermediate language and the optimization decisions. 39443 39444 3. Local transformations (LTRANS) This stage executes in parallel. 39445 All the decisions made during phase 2 are implemented locally in 39446 each partitioned object file, and the final object code is 39447 generated. Optimizations which cannot be decided efficiently 39448 during the phase 2 may be performed on the local call-graph 39449 partitions. 39450 39451 WHOPR can be seen as an extension of the usual LTO mode of 39452compilation. In LTO, WPA and LTRANS are executed within a single 39453execution of the compiler, after the whole program has been read into 39454memory. 39455 39456 When compiling in WHOPR mode, the callgraph is partitioned during the 39457WPA stage. The whole program is split into a given number of 39458partitions of roughly the same size. The compiler tries to minimize 39459the number of references which cross partition boundaries. The main 39460advantage of WHOPR is to allow the parallel execution of LTRANS stages, 39461which are the most time-consuming part of the compilation process. 39462Additionally, it avoids the need to load the whole program into memory. 39463 39464 39465File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 39466 3946724.2 LTO file sections 39468====================== 39469 39470LTO information is stored in several ELF sections inside object files. 39471Data structures and enum codes for sections are defined in 39472`lto-streamer.h'. 39473 39474 These sections are emitted from `lto-streamer-out.c' and mapped in all 39475at once from `lto/lto.c':`lto_file_read'. The individual functions 39476dealing with the reading/writing of each section are described below. 39477 39478 * Command line options (`.gnu.lto_.opts') 39479 39480 This section contains the command line options used to generate the 39481 object files. This is used at link time to determine the 39482 optimization level and other settings when they are not explicitly 39483 specified at the linker command line. 39484 39485 Currently, GCC does not support combining LTO object files compiled 39486 with different set of the command line options into a single 39487 binary. At link time, the options given on the command line and 39488 the options saved on all the files in a link-time set are applied 39489 globally. No attempt is made at validating the combination of 39490 flags (other than the usual validation done by option processing). 39491 This is implemented in `lto/lto.c':`lto_read_all_file_options'. 39492 39493 * Symbol table (`.gnu.lto_.symtab') 39494 39495 This table replaces the ELF symbol table for functions and 39496 variables represented in the LTO IL. Symbols used and exported by 39497 the optimized assembly code of "fat" objects might not match the 39498 ones used and exported by the intermediate code. This table is 39499 necessary because the intermediate code is less optimized and thus 39500 requires a separate symbol table. 39501 39502 Additionally, the binary code in the "fat" object will lack a call 39503 to a function, since the call was optimized out at compilation time 39504 after the intermediate language was streamed out. In some special 39505 cases, the same optimization may not happen during link-time 39506 optimization. This would lead to an undefined symbol if only one 39507 symbol table was used. 39508 39509 The symbol table is emitted in 39510 `lto-streamer-out.c':`produce_symtab'. 39511 39512 * Global declarations and types (`.gnu.lto_.decls') 39513 39514 This section contains an intermediate language dump of all 39515 declarations and types required to represent the callgraph, static 39516 variables and top-level debug info. 39517 39518 The contents of this section are emitted in 39519 `lto-streamer-out.c':`produce_asm_for_decls'. Types and symbols 39520 are emitted in a topological order that preserves the sharing of 39521 pointers when the file is read back in 39522 (`lto.c':`read_cgraph_and_symbols'). 39523 39524 * The callgraph (`.gnu.lto_.cgraph') 39525 39526 This section contains the basic data structure used by the GCC 39527 inter-procedural optimization infrastructure. This section stores 39528 an annotated multi-graph which represents the functions and call 39529 sites as well as the variables, aliases and top-level `asm' 39530 statements. 39531 39532 This section is emitted in `lto-streamer-out.c':`output_cgraph' 39533 and read in `lto-cgraph.c':`input_cgraph'. 39534 39535 * IPA references (`.gnu.lto_.refs') 39536 39537 This section contains references between function and static 39538 variables. It is emitted by `lto-cgraph.c':`output_refs' and read 39539 by `lto-cgraph.c':`input_refs'. 39540 39541 * Function bodies (`.gnu.lto_.function_body.<name>') 39542 39543 This section contains function bodies in the intermediate language 39544 representation. Every function body is in a separate section to 39545 allow copying of the section independently to different object 39546 files or reading the function on demand. 39547 39548 Functions are emitted in `lto-streamer-out.c':`output_function' 39549 and read in `lto-streamer-in.c':`input_function'. 39550 39551 * Static variable initializers (`.gnu.lto_.vars') 39552 39553 This section contains all the symbols in the global variable pool. 39554 It is emitted by `lto-cgraph.c':`output_varpool' and read in 39555 `lto-cgraph.c':`input_cgraph'. 39556 39557 * Summaries and optimization summaries used by IPA passes 39558 (`.gnu.lto_.<xxx>', where `<xxx>' is one of `jmpfuncs', 39559 `pureconst' or `reference') 39560 39561 These sections are used by IPA passes that need to emit summary 39562 information during LTO generation to be read and aggregated at 39563 link time. Each pass is responsible for implementing two pass 39564 manager hooks: one for writing the summary and another for reading 39565 it in. The format of these sections is entirely up to each 39566 individual pass. The only requirement is that the writer and 39567 reader hooks agree on the format. 39568 39569 39570File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 39571 3957224.3 Using summary information in IPA passes 39573============================================ 39574 39575Programs are represented internally as a _callgraph_ (a multi-graph 39576where nodes are functions and edges are call sites) and a _varpool_ (a 39577list of static and external variables in the program). 39578 39579 The inter-procedural optimization is organized as a sequence of 39580individual passes, which operate on the callgraph and the varpool. To 39581make the implementation of WHOPR possible, every inter-procedural 39582optimization pass is split into several stages that are executed at 39583different times during WHOPR compilation: 39584 39585 * LGEN time 39586 1. _Generate summary_ (`generate_summary' in `struct 39587 ipa_opt_pass_d'). This stage analyzes every function body 39588 and variable initializer is examined and stores relevant 39589 information into a pass-specific data structure. 39590 39591 2. _Write summary_ (`write_summary' in `struct ipa_opt_pass_d'). 39592 This stage writes all the pass-specific information generated 39593 by `generate_summary'. Summaries go into their own 39594 `LTO_section_*' sections that have to be declared in 39595 `lto-streamer.h':`enum lto_section_type'. A new section is 39596 created by calling `create_output_block' and data can be 39597 written using the `lto_output_*' routines. 39598 39599 * WPA time 39600 1. _Read summary_ (`read_summary' in `struct ipa_opt_pass_d'). 39601 This stage reads all the pass-specific information in exactly 39602 the same order that it was written by `write_summary'. 39603 39604 2. _Execute_ (`execute' in `struct opt_pass'). This performs 39605 inter-procedural propagation. This must be done without 39606 actual access to the individual function bodies or variable 39607 initializers. Typically, this results in a transitive 39608 closure operation over the summary information of all the 39609 nodes in the callgraph. 39610 39611 3. _Write optimization summary_ (`write_optimization_summary' in 39612 `struct ipa_opt_pass_d'). This writes the result of the 39613 inter-procedural propagation into the object file. This can 39614 use the same data structures and helper routines used in 39615 `write_summary'. 39616 39617 * LTRANS time 39618 1. _Read optimization summary_ (`read_optimization_summary' in 39619 `struct ipa_opt_pass_d'). The counterpart to 39620 `write_optimization_summary'. This reads the interprocedural 39621 optimization decisions in exactly the same format emitted by 39622 `write_optimization_summary'. 39623 39624 2. _Transform_ (`function_transform' and `variable_transform' in 39625 `struct ipa_opt_pass_d'). The actual function bodies and 39626 variable initializers are updated based on the information 39627 passed down from the _Execute_ stage. 39628 39629 The implementation of the inter-procedural passes are shared between 39630LTO, WHOPR and classic non-LTO compilation. 39631 39632 * During the traditional file-by-file mode every pass executes its 39633 own _Generate summary_, _Execute_, and _Transform_ stages within 39634 the single execution context of the compiler. 39635 39636 * In LTO compilation mode, every pass uses _Generate summary_ and 39637 _Write summary_ stages at compilation time, while the _Read 39638 summary_, _Execute_, and _Transform_ stages are executed at link 39639 time. 39640 39641 * In WHOPR mode all stages are used. 39642 39643 To simplify development, the GCC pass manager differentiates between 39644normal inter-procedural passes and small inter-procedural passes. A 39645_small inter-procedural pass_ (`SIMPLE_IPA_PASS') is a pass that does 39646everything at once and thus it can not be executed during WPA in WHOPR 39647mode. It defines only the _Execute_ stage and during this stage it 39648accesses and modifies the function bodies. Such passes are useful for 39649optimization at LGEN or LTRANS time and are used, for example, to 39650implement early optimization before writing object files. The simple 39651inter-procedural passes can also be used for easier prototyping and 39652development of a new inter-procedural pass. 39653 3965424.3.1 Virtual clones 39655--------------------- 39656 39657One of the main challenges of introducing the WHOPR compilation mode 39658was addressing the interactions between optimization passes. In LTO 39659compilation mode, the passes are executed in a sequence, each of which 39660consists of analysis (or _Generate summary_), propagation (or 39661_Execute_) and _Transform_ stages. Once the work of one pass is 39662finished, the next pass sees the updated program representation and can 39663execute. This makes the individual passes dependent on each other. 39664 39665 In WHOPR mode all passes first execute their _Generate summary_ stage. 39666Then summary writing marks the end of the LGEN stage. At WPA time, the 39667summaries are read back into memory and all passes run the _Execute_ 39668stage. Optimization summaries are streamed and sent to LTRANS, where 39669all the passes execute the _Transform_ stage. 39670 39671 Most optimization passes split naturally into analysis, propagation 39672and transformation stages. But some do not. The main problem arises 39673when one pass performs changes and the following pass gets confused by 39674seeing different callgraphs between the _Transform_ stage and the 39675_Generate summary_ or _Execute_ stage. This means that the passes are 39676required to communicate their decisions with each other. 39677 39678 To facilitate this communication, the GCC callgraph infrastructure 39679implements _virtual clones_, a method of representing the changes 39680performed by the optimization passes in the callgraph without needing 39681to update function bodies. 39682 39683 A _virtual clone_ in the callgraph is a function that has no 39684associated body, just a description of how to create its body based on 39685a different function (which itself may be a virtual clone). 39686 39687 The description of function modifications includes adjustments to the 39688function's signature (which allows, for example, removing or adding 39689function arguments), substitutions to perform on the function body, 39690and, for inlined functions, a pointer to the function that it will be 39691inlined into. 39692 39693 It is also possible to redirect any edge of the callgraph from a 39694function to its virtual clone. This implies updating of the call site 39695to adjust for the new function signature. 39696 39697 Most of the transformations performed by inter-procedural 39698optimizations can be represented via virtual clones. For instance, a 39699constant propagation pass can produce a virtual clone of the function 39700which replaces one of its arguments by a constant. The inliner can 39701represent its decisions by producing a clone of a function whose body 39702will be later integrated into a given function. 39703 39704 Using _virtual clones_, the program can be easily updated during the 39705_Execute_ stage, solving most of pass interactions problems that would 39706otherwise occur during _Transform_. 39707 39708 Virtual clones are later materialized in the LTRANS stage and turned 39709into real functions. Passes executed after the virtual clone were 39710introduced also perform their _Transform_ stage on new functions, so 39711for a pass there is no significant difference between operating on a 39712real function or a virtual clone introduced before its _Execute_ stage. 39713 39714 Optimization passes then work on virtual clones introduced before 39715their _Execute_ stage as if they were real functions. The only 39716difference is that clones are not visible during the _Generate Summary_ 39717stage. 39718 39719 To keep function summaries updated, the callgraph interface allows an 39720optimizer to register a callback that is called every time a new clone 39721is introduced as well as when the actual function or variable is 39722generated or when a function or variable is removed. These hooks are 39723registered in the _Generate summary_ stage and allow the pass to keep 39724its information intact until the _Execute_ stage. The same hooks can 39725also be registered during the _Execute_ stage to keep the optimization 39726summaries updated for the _Transform_ stage. 39727 3972824.3.2 IPA references 39729--------------------- 39730 39731GCC represents IPA references in the callgraph. For a function or 39732variable `A', the _IPA reference_ is a list of all locations where the 39733address of `A' is taken and, when `A' is a variable, a list of all 39734direct stores and reads to/from `A'. References represent an oriented 39735multi-graph on the union of nodes of the callgraph and the varpool. See 39736`ipa-reference.c':`ipa_reference_write_optimization_summary' and 39737`ipa-reference.c':`ipa_reference_read_optimization_summary' for details. 39738 3973924.3.3 Jump functions 39740--------------------- 39741 39742Suppose that an optimization pass sees a function `A' and it knows the 39743values of (some of) its arguments. The _jump function_ describes the 39744value of a parameter of a given function call in function `A' based on 39745this knowledge. 39746 39747 Jump functions are used by several optimizations, such as the 39748inter-procedural constant propagation pass and the devirtualization 39749pass. The inliner also uses jump functions to perform inlining of 39750callbacks. 39751 39752 39753File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 39754 3975524.4 Whole program assumptions, linker plugin and symbol visibilities 39756===================================================================== 39757 39758Link-time optimization gives relatively minor benefits when used alone. 39759The problem is that propagation of inter-procedural information does 39760not work well across functions and variables that are called or 39761referenced by other compilation units (such as from a dynamically 39762linked library). We say that such functions and variables are 39763_externally visible_. 39764 39765 To make the situation even more difficult, many applications organize 39766themselves as a set of shared libraries, and the default ELF visibility 39767rules allow one to overwrite any externally visible symbol with a 39768different symbol at runtime. This basically disables any optimizations 39769across such functions and variables, because the compiler cannot be 39770sure that the function body it is seeing is the same function body that 39771will be used at runtime. Any function or variable not declared 39772`static' in the sources degrades the quality of inter-procedural 39773optimization. 39774 39775 To avoid this problem the compiler must assume that it sees the whole 39776program when doing link-time optimization. Strictly speaking, the 39777whole program is rarely visible even at link-time. Standard system 39778libraries are usually linked dynamically or not provided with the 39779link-time information. In GCC, the whole program option 39780(`-fwhole-program') asserts that every function and variable defined in 39781the current compilation unit is static, except for function `main' 39782(note: at link time, the current unit is the union of all objects 39783compiled with LTO). Since some functions and variables need to be 39784referenced externally, for example by another DSO or from an assembler 39785file, GCC also provides the function and variable attribute 39786`externally_visible' which can be used to disable the effect of 39787`-fwhole-program' on a specific symbol. 39788 39789 The whole program mode assumptions are slightly more complex in C++, 39790where inline functions in headers are put into _COMDAT_ sections. 39791COMDAT function and variables can be defined by multiple object files 39792and their bodies are unified at link-time and dynamic link-time. 39793COMDAT functions are changed to local only when their address is not 39794taken and thus un-sharing them with a library is not harmful. COMDAT 39795variables always remain externally visible, however for readonly 39796variables it is assumed that their initializers cannot be overwritten 39797by a different value. 39798 39799 GCC provides the function and variable attribute `visibility' that can 39800be used to specify the visibility of externally visible symbols (or 39801alternatively an `-fdefault-visibility' command line option). ELF 39802defines the `default', `protected', `hidden' and `internal' 39803visibilities. 39804 39805 The most commonly used is visibility is `hidden'. It specifies that 39806the symbol cannot be referenced from outside of the current shared 39807library. Unfortunately, this information cannot be used directly by 39808the link-time optimization in the compiler since the whole shared 39809library also might contain non-LTO objects and those are not visible to 39810the compiler. 39811 39812 GCC solves this problem using linker plugins. A _linker plugin_ is an 39813interface to the linker that allows an external program to claim the 39814ownership of a given object file. The linker then performs the linking 39815procedure by querying the plugin about the symbol table of the claimed 39816objects and once the linking decisions are complete, the plugin is 39817allowed to provide the final object file before the actual linking is 39818made. The linker plugin obtains the symbol resolution information 39819which specifies which symbols provided by the claimed objects are bound 39820from the rest of a binary being linked. 39821 39822 Currently, the linker plugin works only in combination with the Gold 39823linker, but a GNU ld implementation is under development. 39824 39825 GCC is designed to be independent of the rest of the toolchain and 39826aims to support linkers without plugin support. For this reason it 39827does not use the linker plugin by default. Instead, the object files 39828are examined by `collect2' before being passed to the linker and 39829objects found to have LTO sections are passed to `lto1' first. This 39830mode does not work for library archives. The decision on what object 39831files from the archive are needed depends on the actual linking and 39832thus GCC would have to implement the linker itself. The resolution 39833information is missing too and thus GCC needs to make an educated guess 39834based on `-fwhole-program'. Without the linker plugin GCC also assumes 39835that symbols are declared `hidden' and not referred by non-LTO code by 39836default. 39837 39838 39839File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 39840 3984124.5 Internal flags controlling `lto1' 39842====================================== 39843 39844The following flags are passed into `lto1' and are not meant to be used 39845directly from the command line. 39846 39847 * -fwpa This option runs the serial part of the link-time optimizer 39848 performing the inter-procedural propagation (WPA mode). The 39849 compiler reads in summary information from all inputs and performs 39850 an analysis based on summary information only. It generates 39851 object files for subsequent runs of the link-time optimizer where 39852 individual object files are optimized using both summary 39853 information from the WPA mode and the actual function bodies. It 39854 then drives the LTRANS phase. 39855 39856 * -fltrans This option runs the link-time optimizer in the 39857 local-transformation (LTRANS) mode, which reads in output from a 39858 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 39859 optimizes an object and produces the final assembly. 39860 39861 * -fltrans-output-list=FILE This option specifies a file to which 39862 the names of LTRANS output files are written. This option is only 39863 meaningful in conjunction with `-fwpa'. 39864 39865 39866File: gccint.info, Node: Funding, Next: GNU Project, Prev: LTO, Up: Top 39867 39868Funding Free Software 39869********************* 39870 39871If you want to have more free software a few years from now, it makes 39872sense for you to help encourage people to contribute funds for its 39873development. The most effective approach known is to encourage 39874commercial redistributors to donate. 39875 39876 Users of free software systems can boost the pace of development by 39877encouraging for-a-fee distributors to donate part of their selling price 39878to free software developers--the Free Software Foundation, and others. 39879 39880 The way to convince distributors to do this is to demand it and expect 39881it from them. So when you compare distributors, judge them partly by 39882how much they give to free software development. Show distributors 39883they must compete to be the one who gives the most. 39884 39885 To make this approach work, you must insist on numbers that you can 39886compare, such as, "We will donate ten dollars to the Frobnitz project 39887for each disk sold." Don't be satisfied with a vague promise, such as 39888"A portion of the profits are donated," since it doesn't give a basis 39889for comparison. 39890 39891 Even a precise fraction "of the profits from this disk" is not very 39892meaningful, since creative accounting and unrelated business decisions 39893can greatly alter what fraction of the sales price counts as profit. 39894If the price you pay is $50, ten percent of the profit is probably less 39895than a dollar; it might be a few cents, or nothing at all. 39896 39897 Some redistributors do development work themselves. This is useful 39898too; but to keep everyone honest, you need to inquire how much they do, 39899and what kind. Some kinds of development make much more long-term 39900difference than others. For example, maintaining a separate version of 39901a program contributes very little; maintaining the standard version of a 39902program for the whole community contributes much. Easy new ports 39903contribute little, since someone else would surely do them; difficult 39904ports such as adding a new CPU to the GNU Compiler Collection 39905contribute more; major new features or packages contribute the most. 39906 39907 By establishing the idea that supporting further development is "the 39908proper thing to do" when distributing free software for a fee, we can 39909assure a steady flow of resources into making more free software. 39910 39911 Copyright (C) 1994 Free Software Foundation, Inc. 39912 Verbatim copying and redistribution of this section is permitted 39913 without royalty; alteration is not permitted. 39914 39915 39916File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 39917 39918The GNU Project and GNU/Linux 39919***************************** 39920 39921The GNU Project was launched in 1984 to develop a complete Unix-like 39922operating system which is free software: the GNU system. (GNU is a 39923recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 39924Variants of the GNU operating system, which use the kernel Linux, are 39925now widely used; though these systems are often referred to as "Linux", 39926they are more accurately called GNU/Linux systems. 39927 39928 For more information, see: 39929 `http://www.gnu.org/' 39930 `http://www.gnu.org/gnu/linux-and-gnu.html' 39931 39932 39933File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 39934 39935GNU General Public License 39936************************** 39937 39938 Version 3, 29 June 2007 39939 39940 Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/' 39941 39942 Everyone is permitted to copy and distribute verbatim copies of this 39943 license document, but changing it is not allowed. 39944 39945Preamble 39946======== 39947 39948The GNU General Public License is a free, copyleft license for software 39949and other kinds of works. 39950 39951 The licenses for most software and other practical works are designed 39952to take away your freedom to share and change the works. By contrast, 39953the GNU General Public License is intended to guarantee your freedom to 39954share and change all versions of a program-to make sure it remains free 39955software for all its users. We, the Free Software Foundation, use the 39956GNU General Public License for most of our software; it applies also to 39957any other work released this way by its authors. You can apply it to 39958your programs, too. 39959 39960 When we speak of free software, we are referring to freedom, not 39961price. Our General Public Licenses are designed to make sure that you 39962have the freedom to distribute copies of free software (and charge for 39963them if you wish), that you receive source code or can get it if you 39964want it, that you can change the software or use pieces of it in new 39965free programs, and that you know you can do these things. 39966 39967 To protect your rights, we need to prevent others from denying you 39968these rights or asking you to surrender the rights. Therefore, you 39969have certain responsibilities if you distribute copies of the software, 39970or if you modify it: responsibilities to respect the freedom of others. 39971 39972 For example, if you distribute copies of such a program, whether 39973gratis or for a fee, you must pass on to the recipients the same 39974freedoms that you received. You must make sure that they, too, receive 39975or can get the source code. And you must show them these terms so they 39976know their rights. 39977 39978 Developers that use the GNU GPL protect your rights with two steps: 39979(1) assert copyright on the software, and (2) offer you this License 39980giving you legal permission to copy, distribute and/or modify it. 39981 39982 For the developers' and authors' protection, the GPL clearly explains 39983that there is no warranty for this free software. For both users' and 39984authors' sake, the GPL requires that modified versions be marked as 39985changed, so that their problems will not be attributed erroneously to 39986authors of previous versions. 39987 39988 Some devices are designed to deny users access to install or run 39989modified versions of the software inside them, although the 39990manufacturer can do so. This is fundamentally incompatible with the 39991aim of protecting users' freedom to change the software. The 39992systematic pattern of such abuse occurs in the area of products for 39993individuals to use, which is precisely where it is most unacceptable. 39994Therefore, we have designed this version of the GPL to prohibit the 39995practice for those products. If such problems arise substantially in 39996other domains, we stand ready to extend this provision to those domains 39997in future versions of the GPL, as needed to protect the freedom of 39998users. 39999 40000 Finally, every program is threatened constantly by software patents. 40001States should not allow patents to restrict development and use of 40002software on general-purpose computers, but in those that do, we wish to 40003avoid the special danger that patents applied to a free program could 40004make it effectively proprietary. To prevent this, the GPL assures that 40005patents cannot be used to render the program non-free. 40006 40007 The precise terms and conditions for copying, distribution and 40008modification follow. 40009 40010TERMS AND CONDITIONS 40011==================== 40012 40013 0. Definitions. 40014 40015 "This License" refers to version 3 of the GNU General Public 40016 License. 40017 40018 "Copyright" also means copyright-like laws that apply to other 40019 kinds of works, such as semiconductor masks. 40020 40021 "The Program" refers to any copyrightable work licensed under this 40022 License. Each licensee is addressed as "you". "Licensees" and 40023 "recipients" may be individuals or organizations. 40024 40025 To "modify" a work means to copy from or adapt all or part of the 40026 work in a fashion requiring copyright permission, other than the 40027 making of an exact copy. The resulting work is called a "modified 40028 version" of the earlier work or a work "based on" the earlier work. 40029 40030 A "covered work" means either the unmodified Program or a work 40031 based on the Program. 40032 40033 To "propagate" a work means to do anything with it that, without 40034 permission, would make you directly or secondarily liable for 40035 infringement under applicable copyright law, except executing it 40036 on a computer or modifying a private copy. Propagation includes 40037 copying, distribution (with or without modification), making 40038 available to the public, and in some countries other activities as 40039 well. 40040 40041 To "convey" a work means any kind of propagation that enables other 40042 parties to make or receive copies. Mere interaction with a user 40043 through a computer network, with no transfer of a copy, is not 40044 conveying. 40045 40046 An interactive user interface displays "Appropriate Legal Notices" 40047 to the extent that it includes a convenient and prominently visible 40048 feature that (1) displays an appropriate copyright notice, and (2) 40049 tells the user that there is no warranty for the work (except to 40050 the extent that warranties are provided), that licensees may 40051 convey the work under this License, and how to view a copy of this 40052 License. If the interface presents a list of user commands or 40053 options, such as a menu, a prominent item in the list meets this 40054 criterion. 40055 40056 1. Source Code. 40057 40058 The "source code" for a work means the preferred form of the work 40059 for making modifications to it. "Object code" means any 40060 non-source form of a work. 40061 40062 A "Standard Interface" means an interface that either is an 40063 official standard defined by a recognized standards body, or, in 40064 the case of interfaces specified for a particular programming 40065 language, one that is widely used among developers working in that 40066 language. 40067 40068 The "System Libraries" of an executable work include anything, 40069 other than the work as a whole, that (a) is included in the normal 40070 form of packaging a Major Component, but which is not part of that 40071 Major Component, and (b) serves only to enable use of the work 40072 with that Major Component, or to implement a Standard Interface 40073 for which an implementation is available to the public in source 40074 code form. A "Major Component", in this context, means a major 40075 essential component (kernel, window system, and so on) of the 40076 specific operating system (if any) on which the executable work 40077 runs, or a compiler used to produce the work, or an object code 40078 interpreter used to run it. 40079 40080 The "Corresponding Source" for a work in object code form means all 40081 the source code needed to generate, install, and (for an executable 40082 work) run the object code and to modify the work, including 40083 scripts to control those activities. However, it does not include 40084 the work's System Libraries, or general-purpose tools or generally 40085 available free programs which are used unmodified in performing 40086 those activities but which are not part of the work. For example, 40087 Corresponding Source includes interface definition files 40088 associated with source files for the work, and the source code for 40089 shared libraries and dynamically linked subprograms that the work 40090 is specifically designed to require, such as by intimate data 40091 communication or control flow between those subprograms and other 40092 parts of the work. 40093 40094 The Corresponding Source need not include anything that users can 40095 regenerate automatically from other parts of the Corresponding 40096 Source. 40097 40098 The Corresponding Source for a work in source code form is that 40099 same work. 40100 40101 2. Basic Permissions. 40102 40103 All rights granted under this License are granted for the term of 40104 copyright on the Program, and are irrevocable provided the stated 40105 conditions are met. This License explicitly affirms your unlimited 40106 permission to run the unmodified Program. The output from running 40107 a covered work is covered by this License only if the output, 40108 given its content, constitutes a covered work. This License 40109 acknowledges your rights of fair use or other equivalent, as 40110 provided by copyright law. 40111 40112 You may make, run and propagate covered works that you do not 40113 convey, without conditions so long as your license otherwise 40114 remains in force. You may convey covered works to others for the 40115 sole purpose of having them make modifications exclusively for 40116 you, or provide you with facilities for running those works, 40117 provided that you comply with the terms of this License in 40118 conveying all material for which you do not control copyright. 40119 Those thus making or running the covered works for you must do so 40120 exclusively on your behalf, under your direction and control, on 40121 terms that prohibit them from making any copies of your 40122 copyrighted material outside their relationship with you. 40123 40124 Conveying under any other circumstances is permitted solely under 40125 the conditions stated below. Sublicensing is not allowed; section 40126 10 makes it unnecessary. 40127 40128 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 40129 40130 No covered work shall be deemed part of an effective technological 40131 measure under any applicable law fulfilling obligations under 40132 article 11 of the WIPO copyright treaty adopted on 20 December 40133 1996, or similar laws prohibiting or restricting circumvention of 40134 such measures. 40135 40136 When you convey a covered work, you waive any legal power to forbid 40137 circumvention of technological measures to the extent such 40138 circumvention is effected by exercising rights under this License 40139 with respect to the covered work, and you disclaim any intention 40140 to limit operation or modification of the work as a means of 40141 enforcing, against the work's users, your or third parties' legal 40142 rights to forbid circumvention of technological measures. 40143 40144 4. Conveying Verbatim Copies. 40145 40146 You may convey verbatim copies of the Program's source code as you 40147 receive it, in any medium, provided that you conspicuously and 40148 appropriately publish on each copy an appropriate copyright notice; 40149 keep intact all notices stating that this License and any 40150 non-permissive terms added in accord with section 7 apply to the 40151 code; keep intact all notices of the absence of any warranty; and 40152 give all recipients a copy of this License along with the Program. 40153 40154 You may charge any price or no price for each copy that you convey, 40155 and you may offer support or warranty protection for a fee. 40156 40157 5. Conveying Modified Source Versions. 40158 40159 You may convey a work based on the Program, or the modifications to 40160 produce it from the Program, in the form of source code under the 40161 terms of section 4, provided that you also meet all of these 40162 conditions: 40163 40164 a. The work must carry prominent notices stating that you 40165 modified it, and giving a relevant date. 40166 40167 b. The work must carry prominent notices stating that it is 40168 released under this License and any conditions added under 40169 section 7. This requirement modifies the requirement in 40170 section 4 to "keep intact all notices". 40171 40172 c. You must license the entire work, as a whole, under this 40173 License to anyone who comes into possession of a copy. This 40174 License will therefore apply, along with any applicable 40175 section 7 additional terms, to the whole of the work, and all 40176 its parts, regardless of how they are packaged. This License 40177 gives no permission to license the work in any other way, but 40178 it does not invalidate such permission if you have separately 40179 received it. 40180 40181 d. If the work has interactive user interfaces, each must display 40182 Appropriate Legal Notices; however, if the Program has 40183 interactive interfaces that do not display Appropriate Legal 40184 Notices, your work need not make them do so. 40185 40186 A compilation of a covered work with other separate and independent 40187 works, which are not by their nature extensions of the covered 40188 work, and which are not combined with it such as to form a larger 40189 program, in or on a volume of a storage or distribution medium, is 40190 called an "aggregate" if the compilation and its resulting 40191 copyright are not used to limit the access or legal rights of the 40192 compilation's users beyond what the individual works permit. 40193 Inclusion of a covered work in an aggregate does not cause this 40194 License to apply to the other parts of the aggregate. 40195 40196 6. Conveying Non-Source Forms. 40197 40198 You may convey a covered work in object code form under the terms 40199 of sections 4 and 5, provided that you also convey the 40200 machine-readable Corresponding Source under the terms of this 40201 License, in one of these ways: 40202 40203 a. Convey the object code in, or embodied in, a physical product 40204 (including a physical distribution medium), accompanied by the 40205 Corresponding Source fixed on a durable physical medium 40206 customarily used for software interchange. 40207 40208 b. Convey the object code in, or embodied in, a physical product 40209 (including a physical distribution medium), accompanied by a 40210 written offer, valid for at least three years and valid for 40211 as long as you offer spare parts or customer support for that 40212 product model, to give anyone who possesses the object code 40213 either (1) a copy of the Corresponding Source for all the 40214 software in the product that is covered by this License, on a 40215 durable physical medium customarily used for software 40216 interchange, for a price no more than your reasonable cost of 40217 physically performing this conveying of source, or (2) access 40218 to copy the Corresponding Source from a network server at no 40219 charge. 40220 40221 c. Convey individual copies of the object code with a copy of 40222 the written offer to provide the Corresponding Source. This 40223 alternative is allowed only occasionally and noncommercially, 40224 and only if you received the object code with such an offer, 40225 in accord with subsection 6b. 40226 40227 d. Convey the object code by offering access from a designated 40228 place (gratis or for a charge), and offer equivalent access 40229 to the Corresponding Source in the same way through the same 40230 place at no further charge. You need not require recipients 40231 to copy the Corresponding Source along with the object code. 40232 If the place to copy the object code is a network server, the 40233 Corresponding Source may be on a different server (operated 40234 by you or a third party) that supports equivalent copying 40235 facilities, provided you maintain clear directions next to 40236 the object code saying where to find the Corresponding Source. 40237 Regardless of what server hosts the Corresponding Source, you 40238 remain obligated to ensure that it is available for as long 40239 as needed to satisfy these requirements. 40240 40241 e. Convey the object code using peer-to-peer transmission, 40242 provided you inform other peers where the object code and 40243 Corresponding Source of the work are being offered to the 40244 general public at no charge under subsection 6d. 40245 40246 40247 A separable portion of the object code, whose source code is 40248 excluded from the Corresponding Source as a System Library, need 40249 not be included in conveying the object code work. 40250 40251 A "User Product" is either (1) a "consumer product", which means 40252 any tangible personal property which is normally used for personal, 40253 family, or household purposes, or (2) anything designed or sold for 40254 incorporation into a dwelling. In determining whether a product 40255 is a consumer product, doubtful cases shall be resolved in favor of 40256 coverage. For a particular product received by a particular user, 40257 "normally used" refers to a typical or common use of that class of 40258 product, regardless of the status of the particular user or of the 40259 way in which the particular user actually uses, or expects or is 40260 expected to use, the product. A product is a consumer product 40261 regardless of whether the product has substantial commercial, 40262 industrial or non-consumer uses, unless such uses represent the 40263 only significant mode of use of the product. 40264 40265 "Installation Information" for a User Product means any methods, 40266 procedures, authorization keys, or other information required to 40267 install and execute modified versions of a covered work in that 40268 User Product from a modified version of its Corresponding Source. 40269 The information must suffice to ensure that the continued 40270 functioning of the modified object code is in no case prevented or 40271 interfered with solely because modification has been made. 40272 40273 If you convey an object code work under this section in, or with, 40274 or specifically for use in, a User Product, and the conveying 40275 occurs as part of a transaction in which the right of possession 40276 and use of the User Product is transferred to the recipient in 40277 perpetuity or for a fixed term (regardless of how the transaction 40278 is characterized), the Corresponding Source conveyed under this 40279 section must be accompanied by the Installation Information. But 40280 this requirement does not apply if neither you nor any third party 40281 retains the ability to install modified object code on the User 40282 Product (for example, the work has been installed in ROM). 40283 40284 The requirement to provide Installation Information does not 40285 include a requirement to continue to provide support service, 40286 warranty, or updates for a work that has been modified or 40287 installed by the recipient, or for the User Product in which it 40288 has been modified or installed. Access to a network may be denied 40289 when the modification itself materially and adversely affects the 40290 operation of the network or violates the rules and protocols for 40291 communication across the network. 40292 40293 Corresponding Source conveyed, and Installation Information 40294 provided, in accord with this section must be in a format that is 40295 publicly documented (and with an implementation available to the 40296 public in source code form), and must require no special password 40297 or key for unpacking, reading or copying. 40298 40299 7. Additional Terms. 40300 40301 "Additional permissions" are terms that supplement the terms of 40302 this License by making exceptions from one or more of its 40303 conditions. Additional permissions that are applicable to the 40304 entire Program shall be treated as though they were included in 40305 this License, to the extent that they are valid under applicable 40306 law. If additional permissions apply only to part of the Program, 40307 that part may be used separately under those permissions, but the 40308 entire Program remains governed by this License without regard to 40309 the additional permissions. 40310 40311 When you convey a copy of a covered work, you may at your option 40312 remove any additional permissions from that copy, or from any part 40313 of it. (Additional permissions may be written to require their own 40314 removal in certain cases when you modify the work.) You may place 40315 additional permissions on material, added by you to a covered work, 40316 for which you have or can give appropriate copyright permission. 40317 40318 Notwithstanding any other provision of this License, for material 40319 you add to a covered work, you may (if authorized by the copyright 40320 holders of that material) supplement the terms of this License 40321 with terms: 40322 40323 a. Disclaiming warranty or limiting liability differently from 40324 the terms of sections 15 and 16 of this License; or 40325 40326 b. Requiring preservation of specified reasonable legal notices 40327 or author attributions in that material or in the Appropriate 40328 Legal Notices displayed by works containing it; or 40329 40330 c. Prohibiting misrepresentation of the origin of that material, 40331 or requiring that modified versions of such material be 40332 marked in reasonable ways as different from the original 40333 version; or 40334 40335 d. Limiting the use for publicity purposes of names of licensors 40336 or authors of the material; or 40337 40338 e. Declining to grant rights under trademark law for use of some 40339 trade names, trademarks, or service marks; or 40340 40341 f. Requiring indemnification of licensors and authors of that 40342 material by anyone who conveys the material (or modified 40343 versions of it) with contractual assumptions of liability to 40344 the recipient, for any liability that these contractual 40345 assumptions directly impose on those licensors and authors. 40346 40347 All other non-permissive additional terms are considered "further 40348 restrictions" within the meaning of section 10. If the Program as 40349 you received it, or any part of it, contains a notice stating that 40350 it is governed by this License along with a term that is a further 40351 restriction, you may remove that term. If a license document 40352 contains a further restriction but permits relicensing or 40353 conveying under this License, you may add to a covered work 40354 material governed by the terms of that license document, provided 40355 that the further restriction does not survive such relicensing or 40356 conveying. 40357 40358 If you add terms to a covered work in accord with this section, you 40359 must place, in the relevant source files, a statement of the 40360 additional terms that apply to those files, or a notice indicating 40361 where to find the applicable terms. 40362 40363 Additional terms, permissive or non-permissive, may be stated in 40364 the form of a separately written license, or stated as exceptions; 40365 the above requirements apply either way. 40366 40367 8. Termination. 40368 40369 You may not propagate or modify a covered work except as expressly 40370 provided under this License. Any attempt otherwise to propagate or 40371 modify it is void, and will automatically terminate your rights 40372 under this License (including any patent licenses granted under 40373 the third paragraph of section 11). 40374 40375 However, if you cease all violation of this License, then your 40376 license from a particular copyright holder is reinstated (a) 40377 provisionally, unless and until the copyright holder explicitly 40378 and finally terminates your license, and (b) permanently, if the 40379 copyright holder fails to notify you of the violation by some 40380 reasonable means prior to 60 days after the cessation. 40381 40382 Moreover, your license from a particular copyright holder is 40383 reinstated permanently if the copyright holder notifies you of the 40384 violation by some reasonable means, this is the first time you have 40385 received notice of violation of this License (for any work) from 40386 that copyright holder, and you cure the violation prior to 30 days 40387 after your receipt of the notice. 40388 40389 Termination of your rights under this section does not terminate 40390 the licenses of parties who have received copies or rights from 40391 you under this License. If your rights have been terminated and 40392 not permanently reinstated, you do not qualify to receive new 40393 licenses for the same material under section 10. 40394 40395 9. Acceptance Not Required for Having Copies. 40396 40397 You are not required to accept this License in order to receive or 40398 run a copy of the Program. Ancillary propagation of a covered work 40399 occurring solely as a consequence of using peer-to-peer 40400 transmission to receive a copy likewise does not require 40401 acceptance. However, nothing other than this License grants you 40402 permission to propagate or modify any covered work. These actions 40403 infringe copyright if you do not accept this License. Therefore, 40404 by modifying or propagating a covered work, you indicate your 40405 acceptance of this License to do so. 40406 40407 10. Automatic Licensing of Downstream Recipients. 40408 40409 Each time you convey a covered work, the recipient automatically 40410 receives a license from the original licensors, to run, modify and 40411 propagate that work, subject to this License. You are not 40412 responsible for enforcing compliance by third parties with this 40413 License. 40414 40415 An "entity transaction" is a transaction transferring control of an 40416 organization, or substantially all assets of one, or subdividing an 40417 organization, or merging organizations. If propagation of a 40418 covered work results from an entity transaction, each party to that 40419 transaction who receives a copy of the work also receives whatever 40420 licenses to the work the party's predecessor in interest had or 40421 could give under the previous paragraph, plus a right to 40422 possession of the Corresponding Source of the work from the 40423 predecessor in interest, if the predecessor has it or can get it 40424 with reasonable efforts. 40425 40426 You may not impose any further restrictions on the exercise of the 40427 rights granted or affirmed under this License. For example, you 40428 may not impose a license fee, royalty, or other charge for 40429 exercise of rights granted under this License, and you may not 40430 initiate litigation (including a cross-claim or counterclaim in a 40431 lawsuit) alleging that any patent claim is infringed by making, 40432 using, selling, offering for sale, or importing the Program or any 40433 portion of it. 40434 40435 11. Patents. 40436 40437 A "contributor" is a copyright holder who authorizes use under this 40438 License of the Program or a work on which the Program is based. 40439 The work thus licensed is called the contributor's "contributor 40440 version". 40441 40442 A contributor's "essential patent claims" are all patent claims 40443 owned or controlled by the contributor, whether already acquired or 40444 hereafter acquired, that would be infringed by some manner, 40445 permitted by this License, of making, using, or selling its 40446 contributor version, but do not include claims that would be 40447 infringed only as a consequence of further modification of the 40448 contributor version. For purposes of this definition, "control" 40449 includes the right to grant patent sublicenses in a manner 40450 consistent with the requirements of this License. 40451 40452 Each contributor grants you a non-exclusive, worldwide, 40453 royalty-free patent license under the contributor's essential 40454 patent claims, to make, use, sell, offer for sale, import and 40455 otherwise run, modify and propagate the contents of its 40456 contributor version. 40457 40458 In the following three paragraphs, a "patent license" is any 40459 express agreement or commitment, however denominated, not to 40460 enforce a patent (such as an express permission to practice a 40461 patent or covenant not to sue for patent infringement). To 40462 "grant" such a patent license to a party means to make such an 40463 agreement or commitment not to enforce a patent against the party. 40464 40465 If you convey a covered work, knowingly relying on a patent 40466 license, and the Corresponding Source of the work is not available 40467 for anyone to copy, free of charge and under the terms of this 40468 License, through a publicly available network server or other 40469 readily accessible means, then you must either (1) cause the 40470 Corresponding Source to be so available, or (2) arrange to deprive 40471 yourself of the benefit of the patent license for this particular 40472 work, or (3) arrange, in a manner consistent with the requirements 40473 of this License, to extend the patent license to downstream 40474 recipients. "Knowingly relying" means you have actual knowledge 40475 that, but for the patent license, your conveying the covered work 40476 in a country, or your recipient's use of the covered work in a 40477 country, would infringe one or more identifiable patents in that 40478 country that you have reason to believe are valid. 40479 40480 If, pursuant to or in connection with a single transaction or 40481 arrangement, you convey, or propagate by procuring conveyance of, a 40482 covered work, and grant a patent license to some of the parties 40483 receiving the covered work authorizing them to use, propagate, 40484 modify or convey a specific copy of the covered work, then the 40485 patent license you grant is automatically extended to all 40486 recipients of the covered work and works based on it. 40487 40488 A patent license is "discriminatory" if it does not include within 40489 the scope of its coverage, prohibits the exercise of, or is 40490 conditioned on the non-exercise of one or more of the rights that 40491 are specifically granted under this License. You may not convey a 40492 covered work if you are a party to an arrangement with a third 40493 party that is in the business of distributing software, under 40494 which you make payment to the third party based on the extent of 40495 your activity of conveying the work, and under which the third 40496 party grants, to any of the parties who would receive the covered 40497 work from you, a discriminatory patent license (a) in connection 40498 with copies of the covered work conveyed by you (or copies made 40499 from those copies), or (b) primarily for and in connection with 40500 specific products or compilations that contain the covered work, 40501 unless you entered into that arrangement, or that patent license 40502 was granted, prior to 28 March 2007. 40503 40504 Nothing in this License shall be construed as excluding or limiting 40505 any implied license or other defenses to infringement that may 40506 otherwise be available to you under applicable patent law. 40507 40508 12. No Surrender of Others' Freedom. 40509 40510 If conditions are imposed on you (whether by court order, 40511 agreement or otherwise) that contradict the conditions of this 40512 License, they do not excuse you from the conditions of this 40513 License. If you cannot convey a covered work so as to satisfy 40514 simultaneously your obligations under this License and any other 40515 pertinent obligations, then as a consequence you may not convey it 40516 at all. For example, if you agree to terms that obligate you to 40517 collect a royalty for further conveying from those to whom you 40518 convey the Program, the only way you could satisfy both those 40519 terms and this License would be to refrain entirely from conveying 40520 the Program. 40521 40522 13. Use with the GNU Affero General Public License. 40523 40524 Notwithstanding any other provision of this License, you have 40525 permission to link or combine any covered work with a work licensed 40526 under version 3 of the GNU Affero General Public License into a 40527 single combined work, and to convey the resulting work. The terms 40528 of this License will continue to apply to the part which is the 40529 covered work, but the special requirements of the GNU Affero 40530 General Public License, section 13, concerning interaction through 40531 a network will apply to the combination as such. 40532 40533 14. Revised Versions of this License. 40534 40535 The Free Software Foundation may publish revised and/or new 40536 versions of the GNU General Public License from time to time. 40537 Such new versions will be similar in spirit to the present 40538 version, but may differ in detail to address new problems or 40539 concerns. 40540 40541 Each version is given a distinguishing version number. If the 40542 Program specifies that a certain numbered version of the GNU 40543 General Public License "or any later version" applies to it, you 40544 have the option of following the terms and conditions either of 40545 that numbered version or of any later version published by the 40546 Free Software Foundation. If the Program does not specify a 40547 version number of the GNU General Public License, you may choose 40548 any version ever published by the Free Software Foundation. 40549 40550 If the Program specifies that a proxy can decide which future 40551 versions of the GNU General Public License can be used, that 40552 proxy's public statement of acceptance of a version permanently 40553 authorizes you to choose that version for the Program. 40554 40555 Later license versions may give you additional or different 40556 permissions. However, no additional obligations are imposed on any 40557 author or copyright holder as a result of your choosing to follow a 40558 later version. 40559 40560 15. Disclaimer of Warranty. 40561 40562 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 40563 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 40564 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 40565 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 40566 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 40567 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 40568 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 40569 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 40570 NECESSARY SERVICING, REPAIR OR CORRECTION. 40571 40572 16. Limitation of Liability. 40573 40574 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 40575 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 40576 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU 40577 FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 40578 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 40579 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 40580 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 40581 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 40582 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 40583 THE POSSIBILITY OF SUCH DAMAGES. 40584 40585 17. Interpretation of Sections 15 and 16. 40586 40587 If the disclaimer of warranty and limitation of liability provided 40588 above cannot be given local legal effect according to their terms, 40589 reviewing courts shall apply local law that most closely 40590 approximates an absolute waiver of all civil liability in 40591 connection with the Program, unless a warranty or assumption of 40592 liability accompanies a copy of the Program in return for a fee. 40593 40594 40595END OF TERMS AND CONDITIONS 40596=========================== 40597 40598How to Apply These Terms to Your New Programs 40599============================================= 40600 40601If you develop a new program, and you want it to be of the greatest 40602possible use to the public, the best way to achieve this is to make it 40603free software which everyone can redistribute and change under these 40604terms. 40605 40606 To do so, attach the following notices to the program. It is safest 40607to attach them to the start of each source file to most effectively 40608state the exclusion of warranty; and each file should have at least the 40609"copyright" line and a pointer to where the full notice is found. 40610 40611 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 40612 Copyright (C) YEAR NAME OF AUTHOR 40613 40614 This program is free software: you can redistribute it and/or modify 40615 it under the terms of the GNU General Public License as published by 40616 the Free Software Foundation, either version 3 of the License, or (at 40617 your option) any later version. 40618 40619 This program is distributed in the hope that it will be useful, but 40620 WITHOUT ANY WARRANTY; without even the implied warranty of 40621 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 40622 General Public License for more details. 40623 40624 You should have received a copy of the GNU General Public License 40625 along with this program. If not, see `http://www.gnu.org/licenses/'. 40626 40627 Also add information on how to contact you by electronic and paper 40628mail. 40629 40630 If the program does terminal interaction, make it output a short 40631notice like this when it starts in an interactive mode: 40632 40633 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 40634 This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 40635 This is free software, and you are welcome to redistribute it 40636 under certain conditions; type `show c' for details. 40637 40638 The hypothetical commands `show w' and `show c' should show the 40639appropriate parts of the General Public License. Of course, your 40640program's commands might be different; for a GUI interface, you would 40641use an "about box". 40642 40643 You should also get your employer (if you work as a programmer) or 40644school, if any, to sign a "copyright disclaimer" for the program, if 40645necessary. For more information on this, and how to apply and follow 40646the GNU GPL, see `http://www.gnu.org/licenses/'. 40647 40648 The GNU General Public License does not permit incorporating your 40649program into proprietary programs. If your program is a subroutine 40650library, you may consider it more useful to permit linking proprietary 40651applications with the library. If this is what you want to do, use the 40652GNU Lesser General Public License instead of this License. But first, 40653please read `http://www.gnu.org/philosophy/why-not-lgpl.html'. 40654 40655 40656File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 40657 40658GNU Free Documentation License 40659****************************** 40660 40661 Version 1.3, 3 November 2008 40662 40663 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 40664 `http://fsf.org/' 40665 40666 Everyone is permitted to copy and distribute verbatim copies 40667 of this license document, but changing it is not allowed. 40668 40669 0. PREAMBLE 40670 40671 The purpose of this License is to make a manual, textbook, or other 40672 functional and useful document "free" in the sense of freedom: to 40673 assure everyone the effective freedom to copy and redistribute it, 40674 with or without modifying it, either commercially or 40675 noncommercially. Secondarily, this License preserves for the 40676 author and publisher a way to get credit for their work, while not 40677 being considered responsible for modifications made by others. 40678 40679 This License is a kind of "copyleft", which means that derivative 40680 works of the document must themselves be free in the same sense. 40681 It complements the GNU General Public License, which is a copyleft 40682 license designed for free software. 40683 40684 We have designed this License in order to use it for manuals for 40685 free software, because free software needs free documentation: a 40686 free program should come with manuals providing the same freedoms 40687 that the software does. But this License is not limited to 40688 software manuals; it can be used for any textual work, regardless 40689 of subject matter or whether it is published as a printed book. 40690 We recommend this License principally for works whose purpose is 40691 instruction or reference. 40692 40693 1. APPLICABILITY AND DEFINITIONS 40694 40695 This License applies to any manual or other work, in any medium, 40696 that contains a notice placed by the copyright holder saying it 40697 can be distributed under the terms of this License. Such a notice 40698 grants a world-wide, royalty-free license, unlimited in duration, 40699 to use that work under the conditions stated herein. The 40700 "Document", below, refers to any such manual or work. Any member 40701 of the public is a licensee, and is addressed as "you". You 40702 accept the license if you copy, modify or distribute the work in a 40703 way requiring permission under copyright law. 40704 40705 A "Modified Version" of the Document means any work containing the 40706 Document or a portion of it, either copied verbatim, or with 40707 modifications and/or translated into another language. 40708 40709 A "Secondary Section" is a named appendix or a front-matter section 40710 of the Document that deals exclusively with the relationship of the 40711 publishers or authors of the Document to the Document's overall 40712 subject (or to related matters) and contains nothing that could 40713 fall directly within that overall subject. (Thus, if the Document 40714 is in part a textbook of mathematics, a Secondary Section may not 40715 explain any mathematics.) The relationship could be a matter of 40716 historical connection with the subject or with related matters, or 40717 of legal, commercial, philosophical, ethical or political position 40718 regarding them. 40719 40720 The "Invariant Sections" are certain Secondary Sections whose 40721 titles are designated, as being those of Invariant Sections, in 40722 the notice that says that the Document is released under this 40723 License. If a section does not fit the above definition of 40724 Secondary then it is not allowed to be designated as Invariant. 40725 The Document may contain zero Invariant Sections. If the Document 40726 does not identify any Invariant Sections then there are none. 40727 40728 The "Cover Texts" are certain short passages of text that are 40729 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 40730 that says that the Document is released under this License. A 40731 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 40732 be at most 25 words. 40733 40734 A "Transparent" copy of the Document means a machine-readable copy, 40735 represented in a format whose specification is available to the 40736 general public, that is suitable for revising the document 40737 straightforwardly with generic text editors or (for images 40738 composed of pixels) generic paint programs or (for drawings) some 40739 widely available drawing editor, and that is suitable for input to 40740 text formatters or for automatic translation to a variety of 40741 formats suitable for input to text formatters. A copy made in an 40742 otherwise Transparent file format whose markup, or absence of 40743 markup, has been arranged to thwart or discourage subsequent 40744 modification by readers is not Transparent. An image format is 40745 not Transparent if used for any substantial amount of text. A 40746 copy that is not "Transparent" is called "Opaque". 40747 40748 Examples of suitable formats for Transparent copies include plain 40749 ASCII without markup, Texinfo input format, LaTeX input format, 40750 SGML or XML using a publicly available DTD, and 40751 standard-conforming simple HTML, PostScript or PDF designed for 40752 human modification. Examples of transparent image formats include 40753 PNG, XCF and JPG. Opaque formats include proprietary formats that 40754 can be read and edited only by proprietary word processors, SGML or 40755 XML for which the DTD and/or processing tools are not generally 40756 available, and the machine-generated HTML, PostScript or PDF 40757 produced by some word processors for output purposes only. 40758 40759 The "Title Page" means, for a printed book, the title page itself, 40760 plus such following pages as are needed to hold, legibly, the 40761 material this License requires to appear in the title page. For 40762 works in formats which do not have any title page as such, "Title 40763 Page" means the text near the most prominent appearance of the 40764 work's title, preceding the beginning of the body of the text. 40765 40766 The "publisher" means any person or entity that distributes copies 40767 of the Document to the public. 40768 40769 A section "Entitled XYZ" means a named subunit of the Document 40770 whose title either is precisely XYZ or contains XYZ in parentheses 40771 following text that translates XYZ in another language. (Here XYZ 40772 stands for a specific section name mentioned below, such as 40773 "Acknowledgements", "Dedications", "Endorsements", or "History".) 40774 To "Preserve the Title" of such a section when you modify the 40775 Document means that it remains a section "Entitled XYZ" according 40776 to this definition. 40777 40778 The Document may include Warranty Disclaimers next to the notice 40779 which states that this License applies to the Document. These 40780 Warranty Disclaimers are considered to be included by reference in 40781 this License, but only as regards disclaiming warranties: any other 40782 implication that these Warranty Disclaimers may have is void and 40783 has no effect on the meaning of this License. 40784 40785 2. VERBATIM COPYING 40786 40787 You may copy and distribute the Document in any medium, either 40788 commercially or noncommercially, provided that this License, the 40789 copyright notices, and the license notice saying this License 40790 applies to the Document are reproduced in all copies, and that you 40791 add no other conditions whatsoever to those of this License. You 40792 may not use technical measures to obstruct or control the reading 40793 or further copying of the copies you make or distribute. However, 40794 you may accept compensation in exchange for copies. If you 40795 distribute a large enough number of copies you must also follow 40796 the conditions in section 3. 40797 40798 You may also lend copies, under the same conditions stated above, 40799 and you may publicly display copies. 40800 40801 3. COPYING IN QUANTITY 40802 40803 If you publish printed copies (or copies in media that commonly 40804 have printed covers) of the Document, numbering more than 100, and 40805 the Document's license notice requires Cover Texts, you must 40806 enclose the copies in covers that carry, clearly and legibly, all 40807 these Cover Texts: Front-Cover Texts on the front cover, and 40808 Back-Cover Texts on the back cover. Both covers must also clearly 40809 and legibly identify you as the publisher of these copies. The 40810 front cover must present the full title with all words of the 40811 title equally prominent and visible. You may add other material 40812 on the covers in addition. Copying with changes limited to the 40813 covers, as long as they preserve the title of the Document and 40814 satisfy these conditions, can be treated as verbatim copying in 40815 other respects. 40816 40817 If the required texts for either cover are too voluminous to fit 40818 legibly, you should put the first ones listed (as many as fit 40819 reasonably) on the actual cover, and continue the rest onto 40820 adjacent pages. 40821 40822 If you publish or distribute Opaque copies of the Document 40823 numbering more than 100, you must either include a 40824 machine-readable Transparent copy along with each Opaque copy, or 40825 state in or with each Opaque copy a computer-network location from 40826 which the general network-using public has access to download 40827 using public-standard network protocols a complete Transparent 40828 copy of the Document, free of added material. If you use the 40829 latter option, you must take reasonably prudent steps, when you 40830 begin distribution of Opaque copies in quantity, to ensure that 40831 this Transparent copy will remain thus accessible at the stated 40832 location until at least one year after the last time you 40833 distribute an Opaque copy (directly or through your agents or 40834 retailers) of that edition to the public. 40835 40836 It is requested, but not required, that you contact the authors of 40837 the Document well before redistributing any large number of 40838 copies, to give them a chance to provide you with an updated 40839 version of the Document. 40840 40841 4. MODIFICATIONS 40842 40843 You may copy and distribute a Modified Version of the Document 40844 under the conditions of sections 2 and 3 above, provided that you 40845 release the Modified Version under precisely this License, with 40846 the Modified Version filling the role of the Document, thus 40847 licensing distribution and modification of the Modified Version to 40848 whoever possesses a copy of it. In addition, you must do these 40849 things in the Modified Version: 40850 40851 A. Use in the Title Page (and on the covers, if any) a title 40852 distinct from that of the Document, and from those of 40853 previous versions (which should, if there were any, be listed 40854 in the History section of the Document). You may use the 40855 same title as a previous version if the original publisher of 40856 that version gives permission. 40857 40858 B. List on the Title Page, as authors, one or more persons or 40859 entities responsible for authorship of the modifications in 40860 the Modified Version, together with at least five of the 40861 principal authors of the Document (all of its principal 40862 authors, if it has fewer than five), unless they release you 40863 from this requirement. 40864 40865 C. State on the Title page the name of the publisher of the 40866 Modified Version, as the publisher. 40867 40868 D. Preserve all the copyright notices of the Document. 40869 40870 E. Add an appropriate copyright notice for your modifications 40871 adjacent to the other copyright notices. 40872 40873 F. Include, immediately after the copyright notices, a license 40874 notice giving the public permission to use the Modified 40875 Version under the terms of this License, in the form shown in 40876 the Addendum below. 40877 40878 G. Preserve in that license notice the full lists of Invariant 40879 Sections and required Cover Texts given in the Document's 40880 license notice. 40881 40882 H. Include an unaltered copy of this License. 40883 40884 I. Preserve the section Entitled "History", Preserve its Title, 40885 and add to it an item stating at least the title, year, new 40886 authors, and publisher of the Modified Version as given on 40887 the Title Page. If there is no section Entitled "History" in 40888 the Document, create one stating the title, year, authors, 40889 and publisher of the Document as given on its Title Page, 40890 then add an item describing the Modified Version as stated in 40891 the previous sentence. 40892 40893 J. Preserve the network location, if any, given in the Document 40894 for public access to a Transparent copy of the Document, and 40895 likewise the network locations given in the Document for 40896 previous versions it was based on. These may be placed in 40897 the "History" section. You may omit a network location for a 40898 work that was published at least four years before the 40899 Document itself, or if the original publisher of the version 40900 it refers to gives permission. 40901 40902 K. For any section Entitled "Acknowledgements" or "Dedications", 40903 Preserve the Title of the section, and preserve in the 40904 section all the substance and tone of each of the contributor 40905 acknowledgements and/or dedications given therein. 40906 40907 L. Preserve all the Invariant Sections of the Document, 40908 unaltered in their text and in their titles. Section numbers 40909 or the equivalent are not considered part of the section 40910 titles. 40911 40912 M. Delete any section Entitled "Endorsements". Such a section 40913 may not be included in the Modified Version. 40914 40915 N. Do not retitle any existing section to be Entitled 40916 "Endorsements" or to conflict in title with any Invariant 40917 Section. 40918 40919 O. Preserve any Warranty Disclaimers. 40920 40921 If the Modified Version includes new front-matter sections or 40922 appendices that qualify as Secondary Sections and contain no 40923 material copied from the Document, you may at your option 40924 designate some or all of these sections as invariant. To do this, 40925 add their titles to the list of Invariant Sections in the Modified 40926 Version's license notice. These titles must be distinct from any 40927 other section titles. 40928 40929 You may add a section Entitled "Endorsements", provided it contains 40930 nothing but endorsements of your Modified Version by various 40931 parties--for example, statements of peer review or that the text 40932 has been approved by an organization as the authoritative 40933 definition of a standard. 40934 40935 You may add a passage of up to five words as a Front-Cover Text, 40936 and a passage of up to 25 words as a Back-Cover Text, to the end 40937 of the list of Cover Texts in the Modified Version. Only one 40938 passage of Front-Cover Text and one of Back-Cover Text may be 40939 added by (or through arrangements made by) any one entity. If the 40940 Document already includes a cover text for the same cover, 40941 previously added by you or by arrangement made by the same entity 40942 you are acting on behalf of, you may not add another; but you may 40943 replace the old one, on explicit permission from the previous 40944 publisher that added the old one. 40945 40946 The author(s) and publisher(s) of the Document do not by this 40947 License give permission to use their names for publicity for or to 40948 assert or imply endorsement of any Modified Version. 40949 40950 5. COMBINING DOCUMENTS 40951 40952 You may combine the Document with other documents released under 40953 this License, under the terms defined in section 4 above for 40954 modified versions, provided that you include in the combination 40955 all of the Invariant Sections of all of the original documents, 40956 unmodified, and list them all as Invariant Sections of your 40957 combined work in its license notice, and that you preserve all 40958 their Warranty Disclaimers. 40959 40960 The combined work need only contain one copy of this License, and 40961 multiple identical Invariant Sections may be replaced with a single 40962 copy. If there are multiple Invariant Sections with the same name 40963 but different contents, make the title of each such section unique 40964 by adding at the end of it, in parentheses, the name of the 40965 original author or publisher of that section if known, or else a 40966 unique number. Make the same adjustment to the section titles in 40967 the list of Invariant Sections in the license notice of the 40968 combined work. 40969 40970 In the combination, you must combine any sections Entitled 40971 "History" in the various original documents, forming one section 40972 Entitled "History"; likewise combine any sections Entitled 40973 "Acknowledgements", and any sections Entitled "Dedications". You 40974 must delete all sections Entitled "Endorsements." 40975 40976 6. COLLECTIONS OF DOCUMENTS 40977 40978 You may make a collection consisting of the Document and other 40979 documents released under this License, and replace the individual 40980 copies of this License in the various documents with a single copy 40981 that is included in the collection, provided that you follow the 40982 rules of this License for verbatim copying of each of the 40983 documents in all other respects. 40984 40985 You may extract a single document from such a collection, and 40986 distribute it individually under this License, provided you insert 40987 a copy of this License into the extracted document, and follow 40988 this License in all other respects regarding verbatim copying of 40989 that document. 40990 40991 7. AGGREGATION WITH INDEPENDENT WORKS 40992 40993 A compilation of the Document or its derivatives with other 40994 separate and independent documents or works, in or on a volume of 40995 a storage or distribution medium, is called an "aggregate" if the 40996 copyright resulting from the compilation is not used to limit the 40997 legal rights of the compilation's users beyond what the individual 40998 works permit. When the Document is included in an aggregate, this 40999 License does not apply to the other works in the aggregate which 41000 are not themselves derivative works of the Document. 41001 41002 If the Cover Text requirement of section 3 is applicable to these 41003 copies of the Document, then if the Document is less than one half 41004 of the entire aggregate, the Document's Cover Texts may be placed 41005 on covers that bracket the Document within the aggregate, or the 41006 electronic equivalent of covers if the Document is in electronic 41007 form. Otherwise they must appear on printed covers that bracket 41008 the whole aggregate. 41009 41010 8. TRANSLATION 41011 41012 Translation is considered a kind of modification, so you may 41013 distribute translations of the Document under the terms of section 41014 4. Replacing Invariant Sections with translations requires special 41015 permission from their copyright holders, but you may include 41016 translations of some or all Invariant Sections in addition to the 41017 original versions of these Invariant Sections. You may include a 41018 translation of this License, and all the license notices in the 41019 Document, and any Warranty Disclaimers, provided that you also 41020 include the original English version of this License and the 41021 original versions of those notices and disclaimers. In case of a 41022 disagreement between the translation and the original version of 41023 this License or a notice or disclaimer, the original version will 41024 prevail. 41025 41026 If a section in the Document is Entitled "Acknowledgements", 41027 "Dedications", or "History", the requirement (section 4) to 41028 Preserve its Title (section 1) will typically require changing the 41029 actual title. 41030 41031 9. TERMINATION 41032 41033 You may not copy, modify, sublicense, or distribute the Document 41034 except as expressly provided under this License. Any attempt 41035 otherwise to copy, modify, sublicense, or distribute it is void, 41036 and will automatically terminate your rights under this License. 41037 41038 However, if you cease all violation of this License, then your 41039 license from a particular copyright holder is reinstated (a) 41040 provisionally, unless and until the copyright holder explicitly 41041 and finally terminates your license, and (b) permanently, if the 41042 copyright holder fails to notify you of the violation by some 41043 reasonable means prior to 60 days after the cessation. 41044 41045 Moreover, your license from a particular copyright holder is 41046 reinstated permanently if the copyright holder notifies you of the 41047 violation by some reasonable means, this is the first time you have 41048 received notice of violation of this License (for any work) from 41049 that copyright holder, and you cure the violation prior to 30 days 41050 after your receipt of the notice. 41051 41052 Termination of your rights under this section does not terminate 41053 the licenses of parties who have received copies or rights from 41054 you under this License. If your rights have been terminated and 41055 not permanently reinstated, receipt of a copy of some or all of 41056 the same material does not give you any rights to use it. 41057 41058 10. FUTURE REVISIONS OF THIS LICENSE 41059 41060 The Free Software Foundation may publish new, revised versions of 41061 the GNU Free Documentation License from time to time. Such new 41062 versions will be similar in spirit to the present version, but may 41063 differ in detail to address new problems or concerns. See 41064 `http://www.gnu.org/copyleft/'. 41065 41066 Each version of the License is given a distinguishing version 41067 number. If the Document specifies that a particular numbered 41068 version of this License "or any later version" applies to it, you 41069 have the option of following the terms and conditions either of 41070 that specified version or of any later version that has been 41071 published (not as a draft) by the Free Software Foundation. If 41072 the Document does not specify a version number of this License, 41073 you may choose any version ever published (not as a draft) by the 41074 Free Software Foundation. If the Document specifies that a proxy 41075 can decide which future versions of this License can be used, that 41076 proxy's public statement of acceptance of a version permanently 41077 authorizes you to choose that version for the Document. 41078 41079 11. RELICENSING 41080 41081 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 41082 World Wide Web server that publishes copyrightable works and also 41083 provides prominent facilities for anybody to edit those works. A 41084 public wiki that anybody can edit is an example of such a server. 41085 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 41086 site means any set of copyrightable works thus published on the MMC 41087 site. 41088 41089 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 41090 license published by Creative Commons Corporation, a not-for-profit 41091 corporation with a principal place of business in San Francisco, 41092 California, as well as future copyleft versions of that license 41093 published by that same organization. 41094 41095 "Incorporate" means to publish or republish a Document, in whole or 41096 in part, as part of another Document. 41097 41098 An MMC is "eligible for relicensing" if it is licensed under this 41099 License, and if all works that were first published under this 41100 License somewhere other than this MMC, and subsequently 41101 incorporated in whole or in part into the MMC, (1) had no cover 41102 texts or invariant sections, and (2) were thus incorporated prior 41103 to November 1, 2008. 41104 41105 The operator of an MMC Site may republish an MMC contained in the 41106 site under CC-BY-SA on the same site at any time before August 1, 41107 2009, provided the MMC is eligible for relicensing. 41108 41109 41110ADDENDUM: How to use this License for your documents 41111==================================================== 41112 41113To use this License in a document you have written, include a copy of 41114the License in the document and put the following copyright and license 41115notices just after the title page: 41116 41117 Copyright (C) YEAR YOUR NAME. 41118 Permission is granted to copy, distribute and/or modify this document 41119 under the terms of the GNU Free Documentation License, Version 1.3 41120 or any later version published by the Free Software Foundation; 41121 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 41122 Texts. A copy of the license is included in the section entitled ``GNU 41123 Free Documentation License''. 41124 41125 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 41126replace the "with...Texts." line with this: 41127 41128 with the Invariant Sections being LIST THEIR TITLES, with 41129 the Front-Cover Texts being LIST, and with the Back-Cover Texts 41130 being LIST. 41131 41132 If you have Invariant Sections without Cover Texts, or some other 41133combination of the three, merge those two alternatives to suit the 41134situation. 41135 41136 If your document contains nontrivial examples of program code, we 41137recommend releasing these examples in parallel under your choice of 41138free software license, such as the GNU General Public License, to 41139permit their use in free software. 41140 41141 41142File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 41143 41144Contributors to GCC 41145******************* 41146 41147The GCC project would like to thank its many contributors. Without 41148them the project would not have been nearly as successful as it has 41149been. Any omissions in this list are accidental. Feel free to contact 41150<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 41151some of your contributions are not listed. Please keep this list in 41152alphabetical order. 41153 41154 * Analog Devices helped implement the support for complex data types 41155 and iterators. 41156 41157 * John David Anglin for threading-related fixes and improvements to 41158 libstdc++-v3, and the HP-UX port. 41159 41160 * James van Artsdalen wrote the code that makes efficient use of the 41161 Intel 80387 register stack. 41162 41163 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 41164 Series port. 41165 41166 * Alasdair Baird for various bug fixes. 41167 41168 * Giovanni Bajo for analyzing lots of complicated C++ problem 41169 reports. 41170 41171 * Peter Barada for his work to improve code generation for new 41172 ColdFire cores. 41173 41174 * Gerald Baumgartner added the signature extension to the C++ front 41175 end. 41176 41177 * Godmar Back for his Java improvements and encouragement. 41178 41179 * Scott Bambrough for help porting the Java compiler. 41180 41181 * Wolfgang Bangerth for processing tons of bug reports. 41182 41183 * Jon Beniston for his Microsoft Windows port of Java and port to 41184 Lattice Mico32. 41185 41186 * Daniel Berlin for better DWARF2 support, faster/better 41187 optimizations, improved alias analysis, plus migrating GCC to 41188 Bugzilla. 41189 41190 * Geoff Berry for his Java object serialization work and various 41191 patches. 41192 41193 * David Binderman tests weekly snapshots of GCC trunk against Fedora 41194 Rawhide for several architectures. 41195 41196 * Uros Bizjak for the implementation of x87 math built-in functions 41197 and for various middle end and i386 back end improvements and bug 41198 fixes. 41199 41200 * Eric Blake for helping to make GCJ and libgcj conform to the 41201 specifications. 41202 41203 * Janne Blomqvist for contributions to GNU Fortran. 41204 41205 * Segher Boessenkool for various fixes. 41206 41207 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 41208 other Java work. 41209 41210 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 41211 miscellaneous clean-ups. 41212 41213 * Steven Bosscher for integrating the GNU Fortran front end into GCC 41214 and for contributing to the tree-ssa branch. 41215 41216 * Eric Botcazou for fixing middle- and backend bugs left and right. 41217 41218 * Per Bothner for his direction via the steering committee and 41219 various improvements to the infrastructure for supporting new 41220 languages. Chill front end implementation. Initial 41221 implementations of cpplib, fix-header, config.guess, libio, and 41222 past C++ library (libg++) maintainer. Dreaming up, designing and 41223 implementing much of GCJ. 41224 41225 * Devon Bowen helped port GCC to the Tahoe. 41226 41227 * Don Bowman for mips-vxworks contributions. 41228 41229 * Dave Brolley for work on cpplib and Chill. 41230 41231 * Paul Brook for work on the ARM architecture and maintaining GNU 41232 Fortran. 41233 41234 * Robert Brown implemented the support for Encore 32000 systems. 41235 41236 * Christian Bruel for improvements to local store elimination. 41237 41238 * Herman A.J. ten Brugge for various fixes. 41239 41240 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 41241 FAQ. 41242 41243 * Joe Buck for his direction via the steering committee. 41244 41245 * Craig Burley for leadership of the G77 Fortran effort. 41246 41247 * Stephan Buys for contributing Doxygen notes for libstdc++. 41248 41249 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 41250 to the C++ strings, streambufs and formatted I/O, hard detective 41251 work on the frustrating localization issues, and keeping up with 41252 the problem reports. 41253 41254 * John Carr for his alias work, SPARC hacking, infrastructure 41255 improvements, previous contributions to the steering committee, 41256 loop optimizations, etc. 41257 41258 * Stephane Carrez for 68HC11 and 68HC12 ports. 41259 41260 * Steve Chamberlain for support for the Renesas SH and H8 processors 41261 and the PicoJava processor, and for GCJ config fixes. 41262 41263 * Glenn Chambers for help with the GCJ FAQ. 41264 41265 * John-Marc Chandonia for various libgcj patches. 41266 41267 * Denis Chertykov for contributing and maintaining the AVR port, the 41268 first GCC port for an 8-bit architecture. 41269 41270 * Scott Christley for his Objective-C contributions. 41271 41272 * Eric Christopher for his Java porting help and clean-ups. 41273 41274 * Branko Cibej for more warning contributions. 41275 41276 * The GNU Classpath project for all of their merged runtime code. 41277 41278 * Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, `--help', 41279 and other random hacking. 41280 41281 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 41282 41283 * R. Kelley Cook for making GCC buildable from a read-only directory 41284 as well as other miscellaneous build process and documentation 41285 clean-ups. 41286 41287 * Ralf Corsepius for SH testing and minor bug fixing. 41288 41289 * Stan Cox for care and feeding of the x86 port and lots of behind 41290 the scenes hacking. 41291 41292 * Alex Crain provided changes for the 3b1. 41293 41294 * Ian Dall for major improvements to the NS32k port. 41295 41296 * Paul Dale for his work to add uClinux platform support to the m68k 41297 backend. 41298 41299 * Dario Dariol contributed the four varieties of sample programs 41300 that print a copy of their source. 41301 41302 * Russell Davidson for fstream and stringstream fixes in libstdc++. 41303 41304 * Bud Davis for work on the G77 and GNU Fortran compilers. 41305 41306 * Mo DeJong for GCJ and libgcj bug fixes. 41307 41308 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 41309 various bug fixes, and the M32C, MeP, and RL78 ports. 41310 41311 * Arnaud Desitter for helping to debug GNU Fortran. 41312 41313 * Gabriel Dos Reis for contributions to G++, contributions and 41314 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 41315 including `valarray<>', `complex<>', maintaining the numerics 41316 library (including that pesky `<limits>' :-) and keeping 41317 up-to-date anything to do with numbers. 41318 41319 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 41320 ISO C99 support, CFG dumping support, etc., plus support of the 41321 C++ runtime libraries including for all kinds of C interface 41322 issues, contributing and maintaining `complex<>', sanity checking 41323 and disbursement, configuration architecture, libio maintenance, 41324 and early math work. 41325 41326 * Zdenek Dvorak for a new loop unroller and various fixes. 41327 41328 * Michael Eager for his work on the Xilinx MicroBlaze port. 41329 41330 * Richard Earnshaw for his ongoing work with the ARM. 41331 41332 * David Edelsohn for his direction via the steering committee, 41333 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 41334 loop changes, doing the entire AIX port of libstdc++ with his bare 41335 hands, and for ensuring GCC properly keeps working on AIX. 41336 41337 * Kevin Ediger for the floating point formatting of num_put::do_put 41338 in libstdc++. 41339 41340 * Phil Edwards for libstdc++ work including configuration hackery, 41341 documentation maintainer, chief breaker of the web pages, the 41342 occasional iostream bug fix, and work on shared library symbol 41343 versioning. 41344 41345 * Paul Eggert for random hacking all over GCC. 41346 41347 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 41348 configuration support for locales and fstream-related fixes. 41349 41350 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 41351 iostreams. 41352 41353 * Christian Ehrhardt for dealing with bug reports. 41354 41355 * Ben Elliston for his work to move the Objective-C runtime into its 41356 own subdirectory and for his work on autoconf. 41357 41358 * Revital Eres for work on the PowerPC 750CL port. 41359 41360 * Marc Espie for OpenBSD support. 41361 41362 * Doug Evans for much of the global optimization framework, arc, 41363 m32r, and SPARC work. 41364 41365 * Christopher Faylor for his work on the Cygwin port and for caring 41366 and feeding the gcc.gnu.org box and saving its users tons of spam. 41367 41368 * Fred Fish for BeOS support and Ada fixes. 41369 41370 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 41371 41372 * Peter Gerwinski for various bug fixes and the Pascal front end. 41373 41374 * Kaveh R. Ghazi for his direction via the steering committee, 41375 amazing work to make `-W -Wall -W* -Werror' useful, and testing 41376 GCC on a plethora of platforms. Kaveh extends his gratitude to 41377 the CAIP Center at Rutgers University for providing him with 41378 computing resources to work on Free Software from the late 1980s 41379 to 2010. 41380 41381 * John Gilmore for a donation to the FSF earmarked improving GNU 41382 Java. 41383 41384 * Judy Goldberg for c++ contributions. 41385 41386 * Torbjorn Granlund for various fixes and the c-torture testsuite, 41387 multiply- and divide-by-constant optimization, improved long long 41388 support, improved leaf function register allocation, and his 41389 direction via the steering committee. 41390 41391 * Anthony Green for his `-Os' contributions, the moxie port, and 41392 Java front end work. 41393 41394 * Stu Grossman for gdb hacking, allowing GCJ developers to debug 41395 Java code. 41396 41397 * Michael K. Gschwind contributed the port to the PDP-11. 41398 41399 * Richard Guenther for his ongoing middle-end contributions and bug 41400 fixes and for release management. 41401 41402 * Ron Guilmette implemented the `protoize' and `unprotoize' tools, 41403 the support for Dwarf symbolic debugging information, and much of 41404 the support for System V Release 4. He has also worked heavily on 41405 the Intel 386 and 860 support. 41406 41407 * Sumanth Gundapaneni for contributing the CR16 port. 41408 41409 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 41410 GCSE. 41411 41412 * Bruno Haible for improvements in the runtime overhead for EH, new 41413 warnings and assorted bug fixes. 41414 41415 * Andrew Haley for his amazing Java compiler and library efforts. 41416 41417 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 41418 series 300. 41419 41420 * Michael Hayes for various thankless work he's done trying to get 41421 the c30/c40 ports functional. Lots of loop and unroll 41422 improvements and fixes. 41423 41424 * Dara Hazeghi for wading through myriads of target-specific bug 41425 reports. 41426 41427 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 41428 41429 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 41430 work, loop opts, and generally fixing lots of old problems we've 41431 ignored for years, flow rewrite and lots of further stuff, 41432 including reviewing tons of patches. 41433 41434 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 41435 various fixes. 41436 41437 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 41438 contributed the support for the Sony NEWS machine. 41439 41440 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 41441 various fixes. 41442 41443 * Katherine Holcomb for work on GNU Fortran. 41444 41445 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 41446 of testing and bug fixing, particularly of GCC configury code. 41447 41448 * Steve Holmgren for MachTen patches. 41449 41450 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 41451 41452 * Jan Hubicka for his x86 port improvements. 41453 41454 * Falk Hueffner for working on C and optimization bug reports. 41455 41456 * Bernardo Innocenti for his m68k work, including merging of 41457 ColdFire improvements and uClinux support. 41458 41459 * Christian Iseli for various bug fixes. 41460 41461 * Kamil Iskra for general m68k hacking. 41462 41463 * Lee Iverson for random fixes and MIPS testing. 41464 41465 * Andreas Jaeger for testing and benchmarking of GCC and various bug 41466 fixes. 41467 41468 * Jakub Jelinek for his SPARC work and sibling call optimizations as 41469 well as lots of bug fixes and test cases, and for improving the 41470 Java build system. 41471 41472 * Janis Johnson for ia64 testing and fixes, her quality improvement 41473 sidetracks, and web page maintenance. 41474 41475 * Kean Johnston for SCO OpenServer support and various fixes. 41476 41477 * Tim Josling for the sample language treelang based originally on 41478 Richard Kenner's "toy" language. 41479 41480 * Nicolai Josuttis for additional libstdc++ documentation. 41481 41482 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 41483 target. 41484 41485 * Steven G. Kargl for work on GNU Fortran. 41486 41487 * David Kashtan of SRI adapted GCC to VMS. 41488 41489 * Ryszard Kabatek for many, many libstdc++ bug fixes and 41490 optimizations of strings, especially member functions, and for 41491 auto_ptr fixes. 41492 41493 * Geoffrey Keating for his ongoing work to make the PPC work for 41494 GNU/Linux and his automatic regression tester. 41495 41496 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 41497 work in just about every part of libstdc++. 41498 41499 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 41500 MIL-STD-1750A. 41501 41502 * Richard Kenner of the New York University Ultracomputer Research 41503 Laboratory wrote the machine descriptions for the AMD 29000, the 41504 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 41505 support for instruction attributes. He also made changes to 41506 better support RISC processors including changes to common 41507 subexpression elimination, strength reduction, function calling 41508 sequence handling, and condition code support, in addition to 41509 generalizing the code for frame pointer elimination and delay slot 41510 scheduling. Richard Kenner was also the head maintainer of GCC 41511 for several years. 41512 41513 * Mumit Khan for various contributions to the Cygwin and Mingw32 41514 ports and maintaining binary releases for Microsoft Windows hosts, 41515 and for massive libstdc++ porting work to Cygwin/Mingw32. 41516 41517 * Robin Kirkham for cpu32 support. 41518 41519 * Mark Klein for PA improvements. 41520 41521 * Thomas Koenig for various bug fixes. 41522 41523 * Bruce Korb for the new and improved fixincludes code. 41524 41525 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 41526 effort. 41527 41528 * Charles LaBrec contributed the support for the Integrated Solutions 41529 68020 system. 41530 41531 * Asher Langton and Mike Kumbera for contributing Cray pointer 41532 support to GNU Fortran, and for other GNU Fortran improvements. 41533 41534 * Jeff Law for his direction via the steering committee, 41535 coordinating the entire egcs project and GCC 2.95, rolling out 41536 snapshots and releases, handling merges from GCC2, reviewing tons 41537 of patches that might have fallen through the cracks else, and 41538 random but extensive hacking. 41539 41540 * Walter Lee for work on the TILE-Gx and TILEPro ports. 41541 41542 * Marc Lehmann for his direction via the steering committee and 41543 helping with analysis and improvements of x86 performance. 41544 41545 * Victor Leikehman for work on GNU Fortran. 41546 41547 * Ted Lemon wrote parts of the RTL reader and printer. 41548 41549 * Kriang Lerdsuwanakij for C++ improvements including template as 41550 template parameter support, and many C++ fixes. 41551 41552 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 41553 and random work on the Java front end. 41554 41555 * Alain Lichnewsky ported GCC to the MIPS CPU. 41556 41557 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 41558 and patches. 41559 41560 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 41561 41562 * Chen Liqin for various S+core related fixes/improvement, and for 41563 maintaining the S+core port. 41564 41565 * Weiwen Liu for testing and various bug fixes. 41566 41567 * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other 41568 diagnostics fixes and improvements. 41569 41570 * Dave Love for his ongoing work with the Fortran front end and 41571 runtime libraries. 41572 41573 * Martin von Lo"wis for internal consistency checking infrastructure, 41574 various C++ improvements including namespace support, and tons of 41575 assistance with libstdc++/compiler merges. 41576 41577 * H.J. Lu for his previous contributions to the steering committee, 41578 many x86 bug reports, prototype patches, and keeping the GNU/Linux 41579 ports working. 41580 41581 * Greg McGary for random fixes and (someday) bounded pointers. 41582 41583 * Andrew MacLeod for his ongoing work in building a real EH system, 41584 various code generation improvements, work on the global 41585 optimizer, etc. 41586 41587 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 41588 hacking improvements to compile-time performance, overall 41589 knowledge and direction in the area of instruction scheduling, and 41590 design and implementation of the automaton based instruction 41591 scheduler. 41592 41593 * Bob Manson for his behind the scenes work on dejagnu. 41594 41595 * Philip Martin for lots of libstdc++ string and vector iterator 41596 fixes and improvements, and string clean up and testsuites. 41597 41598 * All of the Mauve project contributors, for Java test code. 41599 41600 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 41601 41602 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 41603 41604 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 41605 powerpc, haifa, ECOFF debug support, and other assorted hacking. 41606 41607 * Jason Merrill for his direction via the steering committee and 41608 leading the G++ effort. 41609 41610 * Martin Michlmayr for testing GCC on several architectures using the 41611 entire Debian archive. 41612 41613 * David Miller for his direction via the steering committee, lots of 41614 SPARC work, improvements in jump.c and interfacing with the Linux 41615 kernel developers. 41616 41617 * Gary Miller ported GCC to Charles River Data Systems machines. 41618 41619 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 41620 the entire libstdc++ testsuite namespace-compatible. 41621 41622 * Mark Mitchell for his direction via the steering committee, 41623 mountains of C++ work, load/store hoisting out of loops, alias 41624 analysis improvements, ISO C `restrict' support, and serving as 41625 release manager from 2000 to 2011. 41626 41627 * Alan Modra for various GNU/Linux bits and testing. 41628 41629 * Toon Moene for his direction via the steering committee, Fortran 41630 maintenance, and his ongoing work to make us make Fortran run fast. 41631 41632 * Jason Molenda for major help in the care and feeding of all the 41633 services on the gcc.gnu.org (formerly egcs.cygnus.com) 41634 machine--mail, web services, ftp services, etc etc. Doing all 41635 this work on scrap paper and the backs of envelopes would have 41636 been... difficult. 41637 41638 * Catherine Moore for fixing various ugly problems we have sent her 41639 way, including the haifa bug which was killing the Alpha & PowerPC 41640 Linux kernels. 41641 41642 * Mike Moreton for his various Java patches. 41643 41644 * David Mosberger-Tang for various Alpha improvements, and for the 41645 initial IA-64 port. 41646 41647 * Stephen Moshier contributed the floating point emulator that 41648 assists in cross-compilation and permits support for floating 41649 point numbers wider than 64 bits and for ISO C99 support. 41650 41651 * Bill Moyer for his behind the scenes work on various issues. 41652 41653 * Philippe De Muyter for his work on the m68k port. 41654 41655 * Joseph S. Myers for his work on the PDP-11 port, format checking 41656 and ISO C99 support, and continuous emphasis on (and contributions 41657 to) documentation. 41658 41659 * Nathan Myers for his work on libstdc++-v3: architecture and 41660 authorship through the first three snapshots, including 41661 implementation of locale infrastructure, string, shadow C headers, 41662 and the initial project documentation (DESIGN, CHECKLIST, and so 41663 forth). Later, more work on MT-safe string and shadow headers. 41664 41665 * Felix Natter for documentation on porting libstdc++. 41666 41667 * Nathanael Nerode for cleaning up the configuration/build process. 41668 41669 * NeXT, Inc. donated the front end that supports the Objective-C 41670 language. 41671 41672 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to 41673 the search engine setup, various documentation fixes and other 41674 small fixes. 41675 41676 * Geoff Noer for his work on getting cygwin native builds working. 41677 41678 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 41679 tracking web pages, GIMPLE tuples, and assorted fixes. 41680 41681 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 41682 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and 41683 related infrastructure improvements. 41684 41685 * Alexandre Oliva for various build infrastructure improvements, 41686 scripts and amazing testing work, including keeping libtool issues 41687 sane and happy. 41688 41689 * Stefan Olsson for work on mt_alloc. 41690 41691 * Melissa O'Neill for various NeXT fixes. 41692 41693 * Rainer Orth for random MIPS work, including improvements to GCC's 41694 o32 ABI support, improvements to dejagnu's MIPS support, Java 41695 configuration clean-ups and porting work, and maintaining the 41696 IRIX, Solaris 2, and Tru64 UNIX ports. 41697 41698 * Hartmut Penner for work on the s390 port. 41699 41700 * Paul Petersen wrote the machine description for the Alliant FX/8. 41701 41702 * Alexandre Petit-Bianco for implementing much of the Java compiler 41703 and continued Java maintainership. 41704 41705 * Matthias Pfaller for major improvements to the NS32k port. 41706 41707 * Gerald Pfeifer for his direction via the steering committee, 41708 pointing out lots of problems we need to solve, maintenance of the 41709 web pages, and taking care of documentation maintenance in general. 41710 41711 * Andrew Pinski for processing bug reports by the dozen. 41712 41713 * Ovidiu Predescu for his work on the Objective-C front end and 41714 runtime libraries. 41715 41716 * Jerry Quinn for major performance improvements in C++ formatted 41717 I/O. 41718 41719 * Ken Raeburn for various improvements to checker, MIPS ports and 41720 various cleanups in the compiler. 41721 41722 * Rolf W. Rasmussen for hacking on AWT. 41723 41724 * David Reese of Sun Microsystems contributed to the Solaris on 41725 PowerPC port. 41726 41727 * Volker Reichelt for keeping up with the problem reports. 41728 41729 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 41730 hacking and developing and maintaining the Epiphany port. 41731 41732 * Loren J. Rittle for improvements to libstdc++-v3 including the 41733 FreeBSD port, threading fixes, thread-related configury changes, 41734 critical threading documentation, and solutions to really tricky 41735 I/O problems, as well as keeping GCC properly working on FreeBSD 41736 and continuous testing. 41737 41738 * Craig Rodrigues for processing tons of bug reports. 41739 41740 * Ola Ro"nnerup for work on mt_alloc. 41741 41742 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 41743 41744 * David Ronis inspired and encouraged Craig to rewrite the G77 41745 documentation in texinfo format by contributing a first pass at a 41746 translation of the old `g77-0.5.16/f/DOC' file. 41747 41748 * Ken Rose for fixes to GCC's delay slot filling code. 41749 41750 * Paul Rubin wrote most of the preprocessor. 41751 41752 * Pe'tur Runo'lfsson for major performance improvements in C++ 41753 formatted I/O and large file support in C++ filebuf. 41754 41755 * Chip Salzenberg for libstdc++ patches and improvements to locales, 41756 traits, Makefiles, libio, libtool hackery, and "long long" support. 41757 41758 * Juha Sarlin for improvements to the H8 code generator. 41759 41760 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 41761 300. 41762 41763 * Roger Sayle for improvements to constant folding and GCC's RTL 41764 optimizers as well as for fixing numerous bugs. 41765 41766 * Bradley Schatz for his work on the GCJ FAQ. 41767 41768 * Peter Schauer wrote the code to allow debugging to work on the 41769 Alpha. 41770 41771 * William Schelter did most of the work on the Intel 80386 support. 41772 41773 * Tobias Schlu"ter for work on GNU Fortran. 41774 41775 * Bernd Schmidt for various code generation improvements and major 41776 work in the reload pass, serving as release manager for GCC 41777 2.95.3, and work on the Blackfin and C6X ports. 41778 41779 * Peter Schmid for constant testing of libstdc++--especially 41780 application testing, going above and beyond what was requested for 41781 the release criteria--and libstdc++ header file tweaks. 41782 41783 * Jason Schroeder for jcf-dump patches. 41784 41785 * Andreas Schwab for his work on the m68k port. 41786 41787 * Lars Segerlund for work on GNU Fortran. 41788 41789 * Dodji Seketeli for numerous C++ bug fixes and debug info 41790 improvements. 41791 41792 * Joel Sherrill for his direction via the steering committee, RTEMS 41793 contributions and RTEMS testing. 41794 41795 * Nathan Sidwell for many C++ fixes/improvements. 41796 41797 * Jeffrey Siegal for helping RMS with the original design of GCC, 41798 some code which handles the parse tree and RTL data structures, 41799 constant folding and help with the original VAX & m68k ports. 41800 41801 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 41802 from the LWG (thereby keeping GCC in line with updates from the 41803 ISO). 41804 41805 * Franz Sirl for his ongoing work with making the PPC port stable 41806 for GNU/Linux. 41807 41808 * Andrey Slepuhin for assorted AIX hacking. 41809 41810 * Trevor Smigiel for contributing the SPU port. 41811 41812 * Christopher Smith did the port for Convex machines. 41813 41814 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 41815 41816 * Randy Smith finished the Sun FPA support. 41817 41818 * Scott Snyder for queue, iterator, istream, and string fixes and 41819 libstdc++ testsuite entries. Also for providing the patch to G77 41820 to add rudimentary support for `INTEGER*1', `INTEGER*2', and 41821 `LOGICAL*1'. 41822 41823 * Zdenek Sojka for running automated regression testing of GCC and 41824 reporting numerous bugs. 41825 41826 * Jayant Sonar for contributing the CR16 port. 41827 41828 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 41829 41830 * Richard Stallman, for writing the original GCC and launching the 41831 GNU project. 41832 41833 * Jan Stein of the Chalmers Computer Society provided support for 41834 Genix, as well as part of the 32000 machine description. 41835 41836 * Nigel Stephens for various mips16 related fixes/improvements. 41837 41838 * Jonathan Stone wrote the machine description for the Pyramid 41839 computer. 41840 41841 * Graham Stott for various infrastructure improvements. 41842 41843 * John Stracke for his Java HTTP protocol fixes. 41844 41845 * Mike Stump for his Elxsi port, G++ contributions over the years 41846 and more recently his vxworks contributions 41847 41848 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 41849 41850 * Shigeya Suzuki for this fixes for the bsdi platforms. 41851 41852 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 41853 support, general configury hacking, fixincludes, etc. 41854 41855 * Holger Teutsch provided the support for the Clipper CPU. 41856 41857 * Gary Thomas for his ongoing work to make the PPC work for 41858 GNU/Linux. 41859 41860 * Philipp Thomas for random bug fixes throughout the compiler 41861 41862 * Jason Thorpe for thread support in libstdc++ on NetBSD. 41863 41864 * Kresten Krab Thorup wrote the run time support for the Objective-C 41865 language and the fantastic Java bytecode interpreter. 41866 41867 * Michael Tiemann for random bug fixes, the first instruction 41868 scheduler, initial C++ support, function integration, NS32k, SPARC 41869 and M88k machine description work, delay slot scheduling. 41870 41871 * Andreas Tobler for his work porting libgcj to Darwin. 41872 41873 * Teemu Torma for thread safe exception handling support. 41874 41875 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 41876 definitions, and of the VAX machine description. 41877 41878 * Daniel Towner and Hariharan Sandanagobalane contributed and 41879 maintain the picoChip port. 41880 41881 * Tom Tromey for internationalization support and for his many Java 41882 contributions and libgcj maintainership. 41883 41884 * Lassi Tuura for improvements to config.guess to determine HP 41885 processor types. 41886 41887 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 41888 41889 * Andy Vaught for the design and initial implementation of the GNU 41890 Fortran front end. 41891 41892 * Brent Verner for work with the libstdc++ cshadow files and their 41893 associated configure steps. 41894 41895 * Todd Vierling for contributions for NetBSD ports. 41896 41897 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 41898 guidance. 41899 41900 * Dean Wakerley for converting the install documentation from HTML 41901 to texinfo in time for GCC 3.0. 41902 41903 * Krister Walfridsson for random bug fixes. 41904 41905 * Feng Wang for contributions to GNU Fortran. 41906 41907 * Stephen M. Webb for time and effort on making libstdc++ shadow 41908 files work with the tricky Solaris 8+ headers, and for pushing the 41909 build-time header tree. 41910 41911 * John Wehle for various improvements for the x86 code generator, 41912 related infrastructure improvements to help x86 code generation, 41913 value range propagation and other work, WE32k port. 41914 41915 * Ulrich Weigand for work on the s390 port. 41916 41917 * Zack Weinberg for major work on cpplib and various other bug fixes. 41918 41919 * Matt Welsh for help with Linux Threads support in GCJ. 41920 41921 * Urban Widmark for help fixing java.io. 41922 41923 * Mark Wielaard for new Java library code and his work integrating 41924 with Classpath. 41925 41926 * Dale Wiles helped port GCC to the Tahoe. 41927 41928 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 41929 41930 * Jim Wilson for his direction via the steering committee, tackling 41931 hard problems in various places that nobody else wanted to work 41932 on, strength reduction and other loop optimizations. 41933 41934 * Paul Woegerer and Tal Agmon for the CRX port. 41935 41936 * Carlo Wood for various fixes. 41937 41938 * Tom Wood for work on the m88k port. 41939 41940 * Canqun Yang for work on GNU Fortran. 41941 41942 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 41943 description for the Tron architecture (specifically, the Gmicro). 41944 41945 * Kevin Zachmann helped port GCC to the Tahoe. 41946 41947 * Ayal Zaks for Swing Modulo Scheduling (SMS). 41948 41949 * Xiaoqiang Zhang for work on GNU Fortran. 41950 41951 * Gilles Zunino for help porting Java to Irix. 41952 41953 41954 The following people are recognized for their contributions to GNAT, 41955the Ada front end of GCC: 41956 * Bernard Banner 41957 41958 * Romain Berrendonner 41959 41960 * Geert Bosch 41961 41962 * Emmanuel Briot 41963 41964 * Joel Brobecker 41965 41966 * Ben Brosgol 41967 41968 * Vincent Celier 41969 41970 * Arnaud Charlet 41971 41972 * Chien Chieng 41973 41974 * Cyrille Comar 41975 41976 * Cyrille Crozes 41977 41978 * Robert Dewar 41979 41980 * Gary Dismukes 41981 41982 * Robert Duff 41983 41984 * Ed Falis 41985 41986 * Ramon Fernandez 41987 41988 * Sam Figueroa 41989 41990 * Vasiliy Fofanov 41991 41992 * Michael Friess 41993 41994 * Franco Gasperoni 41995 41996 * Ted Giering 41997 41998 * Matthew Gingell 41999 42000 * Laurent Guerby 42001 42002 * Jerome Guitton 42003 42004 * Olivier Hainque 42005 42006 * Jerome Hugues 42007 42008 * Hristian Kirtchev 42009 42010 * Jerome Lambourg 42011 42012 * Bruno Leclerc 42013 42014 * Albert Lee 42015 42016 * Sean McNeil 42017 42018 * Javier Miranda 42019 42020 * Laurent Nana 42021 42022 * Pascal Obry 42023 42024 * Dong-Ik Oh 42025 42026 * Laurent Pautet 42027 42028 * Brett Porter 42029 42030 * Thomas Quinot 42031 42032 * Nicolas Roche 42033 42034 * Pat Rogers 42035 42036 * Jose Ruiz 42037 42038 * Douglas Rupp 42039 42040 * Sergey Rybin 42041 42042 * Gail Schenker 42043 42044 * Ed Schonberg 42045 42046 * Nicolas Setton 42047 42048 * Samuel Tardieu 42049 42050 42051 The following people are recognized for their contributions of new 42052features, bug reports, testing and integration of classpath/libgcj for 42053GCC version 4.1: 42054 * Lillian Angel for `JTree' implementation and lots Free Swing 42055 additions and bug fixes. 42056 42057 * Wolfgang Baer for `GapContent' bug fixes. 42058 42059 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse 42060 event fixes, lots of Free Swing work including `JTable' editing. 42061 42062 * Stuart Ballard for RMI constant fixes. 42063 42064 * Goffredo Baroncelli for `HTTPURLConnection' fixes. 42065 42066 * Gary Benson for `MessageFormat' fixes. 42067 42068 * Daniel Bonniot for `Serialization' fixes. 42069 42070 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX' 42071 and `DOM xml:id' support. 42072 42073 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes. 42074 42075 * Archie Cobbs for build fixes, VM interface updates, 42076 `URLClassLoader' updates. 42077 42078 * Kelley Cook for build fixes. 42079 42080 * Martin Cordova for Suggestions for better `SocketTimeoutException'. 42081 42082 * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite 42083 and improvements. 42084 42085 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 42086 2D support. Lots of imageio framework additions, lots of AWT and 42087 Free Swing bug fixes. 42088 42089 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization 42090 fixes, better `Proxy' support, bug fixes and IKVM integration. 42091 42092 * Santiago Gala for `AccessControlContext' fixes. 42093 42094 * Nicolas Geoffray for `VMClassLoader' and `AccessController' 42095 improvements. 42096 42097 * David Gilbert for `basic' and `metal' icon and plaf support and 42098 lots of documenting, Lots of Free Swing and metal theme additions. 42099 `MetalIconFactory' implementation. 42100 42101 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers. 42102 42103 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj 42104 build speedups. 42105 42106 * Kim Ho for `JFileChooser' implementation. 42107 42108 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986 42109 updates, `Serialization' fixes, `Properties' XML support and 42110 generic branch work, VMIntegration guide update. 42111 42112 * Bastiaan Huisman for `TimeZone' bug fixing. 42113 42114 * Andreas Jaeger for mprec updates. 42115 42116 * Paul Jenner for better `-Werror' support. 42117 42118 * Ito Kazumitsu for `NetworkInterface' implementation and updates. 42119 42120 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus 42121 bug fixes all over. Lots of Free Swing work including styled text. 42122 42123 * Simon Kitching for `String' cleanups and optimization suggestions. 42124 42125 * Michael Koch for configuration fixes, `Locale' updates, bug and 42126 build fixes. 42127 42128 * Guilhem Lavaux for configuration, thread and channel fixes and 42129 Kaffe integration. JCL native `Pointer' updates. Logger bug fixes. 42130 42131 * David Lichteblau for JCL support library global/local reference 42132 cleanups. 42133 42134 * Aaron Luchko for JDWP updates and documentation fixes. 42135 42136 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex 42137 features. 42138 42139 * Sven de Marothy for BMP imageio support, CSS and `TextLayout' 42140 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes 42141 and implementing the Qt4 peers. 42142 42143 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock, 42144 `SystemLogger' and `FileHandler' rotate implementations, NIO 42145 `FileChannel.map' support, security and policy updates. 42146 42147 * Bryce McKinlay for RMI work. 42148 42149 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 42150 testing and documenting. 42151 42152 * Kalle Olavi Niemitalo for build fixes. 42153 42154 * Rainer Orth for build fixes. 42155 42156 * Andrew Overholt for `File' locking fixes. 42157 42158 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates. 42159 42160 * Olga Rodimina for `MenuSelectionManager' implementation. 42161 42162 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes. 42163 42164 * Julian Scheid for documentation updates and gjdoc support. 42165 42166 * Christian Schlichtherle for zip fixes and cleanups. 42167 42168 * Robert Schuster for documentation updates and beans fixes, 42169 `TreeNode' enumerations and `ActionCommand' and various fixes, XML 42170 and URL, AWT and Free Swing bug fixes. 42171 42172 * Keith Seitz for lots of JDWP work. 42173 42174 * Christian Thalinger for 64-bit cleanups, Configuration and VM 42175 interface fixes and `CACAO' integration, `fdlibm' updates. 42176 42177 * Gael Thomas for `VMClassLoader' boot packages support suggestions. 42178 42179 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4' 42180 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates. 42181 42182 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe 42183 integration. `Qt4' build infrastructure, `SHA1PRNG' and 42184 `GdkPixbugDecoder' updates. 42185 42186 * Tom Tromey for Eclipse integration, generics work, lots of bug 42187 fixes and gcj integration including coordinating The Big Merge. 42188 42189 * Mark Wielaard for bug fixes, packaging and release management, 42190 `Clipboard' implementation, system call interrupts and network 42191 timeouts and `GdkPixpufDecoder' fixes. 42192 42193 42194 In addition to the above, all of which also contributed time and 42195energy in testing GCC, we would like to thank the following for their 42196contributions to testing: 42197 42198 * Michael Abd-El-Malek 42199 42200 * Thomas Arend 42201 42202 * Bonzo Armstrong 42203 42204 * Steven Ashe 42205 42206 * Chris Baldwin 42207 42208 * David Billinghurst 42209 42210 * Jim Blandy 42211 42212 * Stephane Bortzmeyer 42213 42214 * Horst von Brand 42215 42216 * Frank Braun 42217 42218 * Rodney Brown 42219 42220 * Sidney Cadot 42221 42222 * Bradford Castalia 42223 42224 * Robert Clark 42225 42226 * Jonathan Corbet 42227 42228 * Ralph Doncaster 42229 42230 * Richard Emberson 42231 42232 * Levente Farkas 42233 42234 * Graham Fawcett 42235 42236 * Mark Fernyhough 42237 42238 * Robert A. French 42239 42240 * Jo"rgen Freyh 42241 42242 * Mark K. Gardner 42243 42244 * Charles-Antoine Gauthier 42245 42246 * Yung Shing Gene 42247 42248 * David Gilbert 42249 42250 * Simon Gornall 42251 42252 * Fred Gray 42253 42254 * John Griffin 42255 42256 * Patrik Hagglund 42257 42258 * Phil Hargett 42259 42260 * Amancio Hasty 42261 42262 * Takafumi Hayashi 42263 42264 * Bryan W. Headley 42265 42266 * Kevin B. Hendricks 42267 42268 * Joep Jansen 42269 42270 * Christian Joensson 42271 42272 * Michel Kern 42273 42274 * David Kidd 42275 42276 * Tobias Kuipers 42277 42278 * Anand Krishnaswamy 42279 42280 * A. O. V. Le Blanc 42281 42282 * llewelly 42283 42284 * Damon Love 42285 42286 * Brad Lucier 42287 42288 * Matthias Klose 42289 42290 * Martin Knoblauch 42291 42292 * Rick Lutowski 42293 42294 * Jesse Macnish 42295 42296 * Stefan Morrell 42297 42298 * Anon A. Mous 42299 42300 * Matthias Mueller 42301 42302 * Pekka Nikander 42303 42304 * Rick Niles 42305 42306 * Jon Olson 42307 42308 * Magnus Persson 42309 42310 * Chris Pollard 42311 42312 * Richard Polton 42313 42314 * Derk Reefman 42315 42316 * David Rees 42317 42318 * Paul Reilly 42319 42320 * Tom Reilly 42321 42322 * Torsten Rueger 42323 42324 * Danny Sadinoff 42325 42326 * Marc Schifer 42327 42328 * Erik Schnetter 42329 42330 * Wayne K. Schroll 42331 42332 * David Schuler 42333 42334 * Vin Shelton 42335 42336 * Tim Souder 42337 42338 * Adam Sulmicki 42339 42340 * Bill Thorson 42341 42342 * George Talbot 42343 42344 * Pedro A. M. Vazquez 42345 42346 * Gregory Warnes 42347 42348 * Ian Watson 42349 42350 * David E. Young 42351 42352 * And many others 42353 42354 And finally we'd like to thank everyone who uses the compiler, provides 42355feedback and generally reminds us why we're doing this work in the first 42356place. 42357 42358 42359File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 42360 42361Option Index 42362************ 42363 42364GCC's command line options are indexed here without any initial `-' or 42365`--'. Where an option has both positive and negative forms (such as 42366`-fOPTION' and `-fno-OPTION'), relevant entries in the manual are 42367indexed under the most appropriate form; it may sometimes be useful to 42368look up both forms. 42369 42370�[index�] 42371* Menu: 42372 42373* fltrans: Internal flags. (line 18) 42374* fltrans-output-list: Internal flags. (line 23) 42375* fwpa: Internal flags. (line 9) 42376* msoft-float: Soft float library routines. 42377 (line 6) 42378 42379 42380File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 42381 42382Concept Index 42383************* 42384 42385�[index�] 42386* Menu: 42387 42388* ! in constraint: Multi-Alternative. (line 47) 42389* # in constraint: Modifiers. (line 67) 42390* # in template: Output Template. (line 66) 42391* #pragma: Misc. (line 379) 42392* % in constraint: Modifiers. (line 45) 42393* % in GTY option: GTY Options. (line 18) 42394* % in template: Output Template. (line 6) 42395* & in constraint: Modifiers. (line 25) 42396* (nil): RTL Objects. (line 73) 42397* * in constraint: Modifiers. (line 72) 42398* * in template: Output Statement. (line 29) 42399* + in constraint: Modifiers. (line 12) 42400* -fsection-anchors <1>: Anchored Addresses. (line 6) 42401* -fsection-anchors: Special Accessors. (line 120) 42402* /c in RTL dump: Flags. (line 221) 42403* /f in RTL dump: Flags. (line 229) 42404* /i in RTL dump: Flags. (line 274) 42405* /j in RTL dump: Flags. (line 286) 42406* /s in RTL dump: Flags. (line 245) 42407* /u in RTL dump: Flags. (line 296) 42408* /v in RTL dump: Flags. (line 328) 42409* 0 in constraint: Simple Constraints. (line 130) 42410* < in constraint: Simple Constraints. (line 48) 42411* = in constraint: Modifiers. (line 8) 42412* > in constraint: Simple Constraints. (line 61) 42413* ? in constraint: Multi-Alternative. (line 41) 42414* \: Output Template. (line 46) 42415* __absvdi2: Integer library routines. 42416 (line 107) 42417* __absvsi2: Integer library routines. 42418 (line 106) 42419* __addda3: Fixed-point fractional library routines. 42420 (line 45) 42421* __adddf3: Soft float library routines. 42422 (line 23) 42423* __adddq3: Fixed-point fractional library routines. 42424 (line 33) 42425* __addha3: Fixed-point fractional library routines. 42426 (line 43) 42427* __addhq3: Fixed-point fractional library routines. 42428 (line 30) 42429* __addqq3: Fixed-point fractional library routines. 42430 (line 29) 42431* __addsa3: Fixed-point fractional library routines. 42432 (line 44) 42433* __addsf3: Soft float library routines. 42434 (line 22) 42435* __addsq3: Fixed-point fractional library routines. 42436 (line 31) 42437* __addta3: Fixed-point fractional library routines. 42438 (line 47) 42439* __addtf3: Soft float library routines. 42440 (line 25) 42441* __adduda3: Fixed-point fractional library routines. 42442 (line 53) 42443* __addudq3: Fixed-point fractional library routines. 42444 (line 41) 42445* __adduha3: Fixed-point fractional library routines. 42446 (line 49) 42447* __adduhq3: Fixed-point fractional library routines. 42448 (line 37) 42449* __adduqq3: Fixed-point fractional library routines. 42450 (line 35) 42451* __addusa3: Fixed-point fractional library routines. 42452 (line 51) 42453* __addusq3: Fixed-point fractional library routines. 42454 (line 39) 42455* __adduta3: Fixed-point fractional library routines. 42456 (line 55) 42457* __addvdi3: Integer library routines. 42458 (line 111) 42459* __addvsi3: Integer library routines. 42460 (line 110) 42461* __addxf3: Soft float library routines. 42462 (line 27) 42463* __ashlda3: Fixed-point fractional library routines. 42464 (line 351) 42465* __ashldi3: Integer library routines. 42466 (line 14) 42467* __ashldq3: Fixed-point fractional library routines. 42468 (line 340) 42469* __ashlha3: Fixed-point fractional library routines. 42470 (line 349) 42471* __ashlhq3: Fixed-point fractional library routines. 42472 (line 337) 42473* __ashlqq3: Fixed-point fractional library routines. 42474 (line 336) 42475* __ashlsa3: Fixed-point fractional library routines. 42476 (line 350) 42477* __ashlsi3: Integer library routines. 42478 (line 13) 42479* __ashlsq3: Fixed-point fractional library routines. 42480 (line 338) 42481* __ashlta3: Fixed-point fractional library routines. 42482 (line 353) 42483* __ashlti3: Integer library routines. 42484 (line 15) 42485* __ashluda3: Fixed-point fractional library routines. 42486 (line 359) 42487* __ashludq3: Fixed-point fractional library routines. 42488 (line 348) 42489* __ashluha3: Fixed-point fractional library routines. 42490 (line 355) 42491* __ashluhq3: Fixed-point fractional library routines. 42492 (line 344) 42493* __ashluqq3: Fixed-point fractional library routines. 42494 (line 342) 42495* __ashlusa3: Fixed-point fractional library routines. 42496 (line 357) 42497* __ashlusq3: Fixed-point fractional library routines. 42498 (line 346) 42499* __ashluta3: Fixed-point fractional library routines. 42500 (line 361) 42501* __ashrda3: Fixed-point fractional library routines. 42502 (line 371) 42503* __ashrdi3: Integer library routines. 42504 (line 19) 42505* __ashrdq3: Fixed-point fractional library routines. 42506 (line 368) 42507* __ashrha3: Fixed-point fractional library routines. 42508 (line 369) 42509* __ashrhq3: Fixed-point fractional library routines. 42510 (line 365) 42511* __ashrqq3: Fixed-point fractional library routines. 42512 (line 364) 42513* __ashrsa3: Fixed-point fractional library routines. 42514 (line 370) 42515* __ashrsi3: Integer library routines. 42516 (line 18) 42517* __ashrsq3: Fixed-point fractional library routines. 42518 (line 366) 42519* __ashrta3: Fixed-point fractional library routines. 42520 (line 373) 42521* __ashrti3: Integer library routines. 42522 (line 20) 42523* __bid_adddd3: Decimal float library routines. 42524 (line 25) 42525* __bid_addsd3: Decimal float library routines. 42526 (line 21) 42527* __bid_addtd3: Decimal float library routines. 42528 (line 29) 42529* __bid_divdd3: Decimal float library routines. 42530 (line 68) 42531* __bid_divsd3: Decimal float library routines. 42532 (line 64) 42533* __bid_divtd3: Decimal float library routines. 42534 (line 72) 42535* __bid_eqdd2: Decimal float library routines. 42536 (line 259) 42537* __bid_eqsd2: Decimal float library routines. 42538 (line 257) 42539* __bid_eqtd2: Decimal float library routines. 42540 (line 261) 42541* __bid_extendddtd2: Decimal float library routines. 42542 (line 92) 42543* __bid_extendddtf: Decimal float library routines. 42544 (line 140) 42545* __bid_extendddxf: Decimal float library routines. 42546 (line 134) 42547* __bid_extenddfdd: Decimal float library routines. 42548 (line 147) 42549* __bid_extenddftd: Decimal float library routines. 42550 (line 107) 42551* __bid_extendsddd2: Decimal float library routines. 42552 (line 88) 42553* __bid_extendsddf: Decimal float library routines. 42554 (line 128) 42555* __bid_extendsdtd2: Decimal float library routines. 42556 (line 90) 42557* __bid_extendsdtf: Decimal float library routines. 42558 (line 138) 42559* __bid_extendsdxf: Decimal float library routines. 42560 (line 132) 42561* __bid_extendsfdd: Decimal float library routines. 42562 (line 103) 42563* __bid_extendsfsd: Decimal float library routines. 42564 (line 145) 42565* __bid_extendsftd: Decimal float library routines. 42566 (line 105) 42567* __bid_extendtftd: Decimal float library routines. 42568 (line 149) 42569* __bid_extendxftd: Decimal float library routines. 42570 (line 109) 42571* __bid_fixdddi: Decimal float library routines. 42572 (line 170) 42573* __bid_fixddsi: Decimal float library routines. 42574 (line 162) 42575* __bid_fixsddi: Decimal float library routines. 42576 (line 168) 42577* __bid_fixsdsi: Decimal float library routines. 42578 (line 160) 42579* __bid_fixtddi: Decimal float library routines. 42580 (line 172) 42581* __bid_fixtdsi: Decimal float library routines. 42582 (line 164) 42583* __bid_fixunsdddi: Decimal float library routines. 42584 (line 187) 42585* __bid_fixunsddsi: Decimal float library routines. 42586 (line 178) 42587* __bid_fixunssddi: Decimal float library routines. 42588 (line 185) 42589* __bid_fixunssdsi: Decimal float library routines. 42590 (line 176) 42591* __bid_fixunstddi: Decimal float library routines. 42592 (line 189) 42593* __bid_fixunstdsi: Decimal float library routines. 42594 (line 180) 42595* __bid_floatdidd: Decimal float library routines. 42596 (line 205) 42597* __bid_floatdisd: Decimal float library routines. 42598 (line 203) 42599* __bid_floatditd: Decimal float library routines. 42600 (line 207) 42601* __bid_floatsidd: Decimal float library routines. 42602 (line 196) 42603* __bid_floatsisd: Decimal float library routines. 42604 (line 194) 42605* __bid_floatsitd: Decimal float library routines. 42606 (line 198) 42607* __bid_floatunsdidd: Decimal float library routines. 42608 (line 223) 42609* __bid_floatunsdisd: Decimal float library routines. 42610 (line 221) 42611* __bid_floatunsditd: Decimal float library routines. 42612 (line 225) 42613* __bid_floatunssidd: Decimal float library routines. 42614 (line 214) 42615* __bid_floatunssisd: Decimal float library routines. 42616 (line 212) 42617* __bid_floatunssitd: Decimal float library routines. 42618 (line 216) 42619* __bid_gedd2: Decimal float library routines. 42620 (line 277) 42621* __bid_gesd2: Decimal float library routines. 42622 (line 275) 42623* __bid_getd2: Decimal float library routines. 42624 (line 279) 42625* __bid_gtdd2: Decimal float library routines. 42626 (line 304) 42627* __bid_gtsd2: Decimal float library routines. 42628 (line 302) 42629* __bid_gttd2: Decimal float library routines. 42630 (line 306) 42631* __bid_ledd2: Decimal float library routines. 42632 (line 295) 42633* __bid_lesd2: Decimal float library routines. 42634 (line 293) 42635* __bid_letd2: Decimal float library routines. 42636 (line 297) 42637* __bid_ltdd2: Decimal float library routines. 42638 (line 286) 42639* __bid_ltsd2: Decimal float library routines. 42640 (line 284) 42641* __bid_lttd2: Decimal float library routines. 42642 (line 288) 42643* __bid_muldd3: Decimal float library routines. 42644 (line 54) 42645* __bid_mulsd3: Decimal float library routines. 42646 (line 50) 42647* __bid_multd3: Decimal float library routines. 42648 (line 58) 42649* __bid_nedd2: Decimal float library routines. 42650 (line 268) 42651* __bid_negdd2: Decimal float library routines. 42652 (line 78) 42653* __bid_negsd2: Decimal float library routines. 42654 (line 76) 42655* __bid_negtd2: Decimal float library routines. 42656 (line 80) 42657* __bid_nesd2: Decimal float library routines. 42658 (line 266) 42659* __bid_netd2: Decimal float library routines. 42660 (line 270) 42661* __bid_subdd3: Decimal float library routines. 42662 (line 39) 42663* __bid_subsd3: Decimal float library routines. 42664 (line 35) 42665* __bid_subtd3: Decimal float library routines. 42666 (line 43) 42667* __bid_truncdddf: Decimal float library routines. 42668 (line 153) 42669* __bid_truncddsd2: Decimal float library routines. 42670 (line 94) 42671* __bid_truncddsf: Decimal float library routines. 42672 (line 124) 42673* __bid_truncdfsd: Decimal float library routines. 42674 (line 111) 42675* __bid_truncsdsf: Decimal float library routines. 42676 (line 151) 42677* __bid_trunctddd2: Decimal float library routines. 42678 (line 98) 42679* __bid_trunctddf: Decimal float library routines. 42680 (line 130) 42681* __bid_trunctdsd2: Decimal float library routines. 42682 (line 96) 42683* __bid_trunctdsf: Decimal float library routines. 42684 (line 126) 42685* __bid_trunctdtf: Decimal float library routines. 42686 (line 155) 42687* __bid_trunctdxf: Decimal float library routines. 42688 (line 136) 42689* __bid_trunctfdd: Decimal float library routines. 42690 (line 119) 42691* __bid_trunctfsd: Decimal float library routines. 42692 (line 115) 42693* __bid_truncxfdd: Decimal float library routines. 42694 (line 117) 42695* __bid_truncxfsd: Decimal float library routines. 42696 (line 113) 42697* __bid_unorddd2: Decimal float library routines. 42698 (line 235) 42699* __bid_unordsd2: Decimal float library routines. 42700 (line 233) 42701* __bid_unordtd2: Decimal float library routines. 42702 (line 237) 42703* __bswapdi2: Integer library routines. 42704 (line 162) 42705* __bswapsi2: Integer library routines. 42706 (line 161) 42707* __builtin_classify_type: Varargs. (line 51) 42708* __builtin_next_arg: Varargs. (line 42) 42709* __builtin_saveregs: Varargs. (line 24) 42710* __clear_cache: Miscellaneous routines. 42711 (line 10) 42712* __clzdi2: Integer library routines. 42713 (line 131) 42714* __clzsi2: Integer library routines. 42715 (line 130) 42716* __clzti2: Integer library routines. 42717 (line 132) 42718* __cmpda2: Fixed-point fractional library routines. 42719 (line 451) 42720* __cmpdf2: Soft float library routines. 42721 (line 164) 42722* __cmpdi2: Integer library routines. 42723 (line 87) 42724* __cmpdq2: Fixed-point fractional library routines. 42725 (line 441) 42726* __cmpha2: Fixed-point fractional library routines. 42727 (line 449) 42728* __cmphq2: Fixed-point fractional library routines. 42729 (line 438) 42730* __cmpqq2: Fixed-point fractional library routines. 42731 (line 437) 42732* __cmpsa2: Fixed-point fractional library routines. 42733 (line 450) 42734* __cmpsf2: Soft float library routines. 42735 (line 163) 42736* __cmpsq2: Fixed-point fractional library routines. 42737 (line 439) 42738* __cmpta2: Fixed-point fractional library routines. 42739 (line 453) 42740* __cmptf2: Soft float library routines. 42741 (line 165) 42742* __cmpti2: Integer library routines. 42743 (line 88) 42744* __cmpuda2: Fixed-point fractional library routines. 42745 (line 458) 42746* __cmpudq2: Fixed-point fractional library routines. 42747 (line 448) 42748* __cmpuha2: Fixed-point fractional library routines. 42749 (line 455) 42750* __cmpuhq2: Fixed-point fractional library routines. 42751 (line 444) 42752* __cmpuqq2: Fixed-point fractional library routines. 42753 (line 443) 42754* __cmpusa2: Fixed-point fractional library routines. 42755 (line 456) 42756* __cmpusq2: Fixed-point fractional library routines. 42757 (line 446) 42758* __cmputa2: Fixed-point fractional library routines. 42759 (line 460) 42760* __CTOR_LIST__: Initialization. (line 25) 42761* __ctzdi2: Integer library routines. 42762 (line 138) 42763* __ctzsi2: Integer library routines. 42764 (line 137) 42765* __ctzti2: Integer library routines. 42766 (line 139) 42767* __divda3: Fixed-point fractional library routines. 42768 (line 227) 42769* __divdc3: Soft float library routines. 42770 (line 252) 42771* __divdf3: Soft float library routines. 42772 (line 48) 42773* __divdi3: Integer library routines. 42774 (line 25) 42775* __divdq3: Fixed-point fractional library routines. 42776 (line 223) 42777* __divha3: Fixed-point fractional library routines. 42778 (line 225) 42779* __divhq3: Fixed-point fractional library routines. 42780 (line 220) 42781* __divqq3: Fixed-point fractional library routines. 42782 (line 219) 42783* __divsa3: Fixed-point fractional library routines. 42784 (line 226) 42785* __divsc3: Soft float library routines. 42786 (line 250) 42787* __divsf3: Soft float library routines. 42788 (line 47) 42789* __divsi3: Integer library routines. 42790 (line 24) 42791* __divsq3: Fixed-point fractional library routines. 42792 (line 221) 42793* __divta3: Fixed-point fractional library routines. 42794 (line 229) 42795* __divtc3: Soft float library routines. 42796 (line 254) 42797* __divtf3: Soft float library routines. 42798 (line 50) 42799* __divti3: Integer library routines. 42800 (line 26) 42801* __divxc3: Soft float library routines. 42802 (line 256) 42803* __divxf3: Soft float library routines. 42804 (line 52) 42805* __dpd_adddd3: Decimal float library routines. 42806 (line 23) 42807* __dpd_addsd3: Decimal float library routines. 42808 (line 19) 42809* __dpd_addtd3: Decimal float library routines. 42810 (line 27) 42811* __dpd_divdd3: Decimal float library routines. 42812 (line 66) 42813* __dpd_divsd3: Decimal float library routines. 42814 (line 62) 42815* __dpd_divtd3: Decimal float library routines. 42816 (line 70) 42817* __dpd_eqdd2: Decimal float library routines. 42818 (line 258) 42819* __dpd_eqsd2: Decimal float library routines. 42820 (line 256) 42821* __dpd_eqtd2: Decimal float library routines. 42822 (line 260) 42823* __dpd_extendddtd2: Decimal float library routines. 42824 (line 91) 42825* __dpd_extendddtf: Decimal float library routines. 42826 (line 139) 42827* __dpd_extendddxf: Decimal float library routines. 42828 (line 133) 42829* __dpd_extenddfdd: Decimal float library routines. 42830 (line 146) 42831* __dpd_extenddftd: Decimal float library routines. 42832 (line 106) 42833* __dpd_extendsddd2: Decimal float library routines. 42834 (line 87) 42835* __dpd_extendsddf: Decimal float library routines. 42836 (line 127) 42837* __dpd_extendsdtd2: Decimal float library routines. 42838 (line 89) 42839* __dpd_extendsdtf: Decimal float library routines. 42840 (line 137) 42841* __dpd_extendsdxf: Decimal float library routines. 42842 (line 131) 42843* __dpd_extendsfdd: Decimal float library routines. 42844 (line 102) 42845* __dpd_extendsfsd: Decimal float library routines. 42846 (line 144) 42847* __dpd_extendsftd: Decimal float library routines. 42848 (line 104) 42849* __dpd_extendtftd: Decimal float library routines. 42850 (line 148) 42851* __dpd_extendxftd: Decimal float library routines. 42852 (line 108) 42853* __dpd_fixdddi: Decimal float library routines. 42854 (line 169) 42855* __dpd_fixddsi: Decimal float library routines. 42856 (line 161) 42857* __dpd_fixsddi: Decimal float library routines. 42858 (line 167) 42859* __dpd_fixsdsi: Decimal float library routines. 42860 (line 159) 42861* __dpd_fixtddi: Decimal float library routines. 42862 (line 171) 42863* __dpd_fixtdsi: Decimal float library routines. 42864 (line 163) 42865* __dpd_fixunsdddi: Decimal float library routines. 42866 (line 186) 42867* __dpd_fixunsddsi: Decimal float library routines. 42868 (line 177) 42869* __dpd_fixunssddi: Decimal float library routines. 42870 (line 184) 42871* __dpd_fixunssdsi: Decimal float library routines. 42872 (line 175) 42873* __dpd_fixunstddi: Decimal float library routines. 42874 (line 188) 42875* __dpd_fixunstdsi: Decimal float library routines. 42876 (line 179) 42877* __dpd_floatdidd: Decimal float library routines. 42878 (line 204) 42879* __dpd_floatdisd: Decimal float library routines. 42880 (line 202) 42881* __dpd_floatditd: Decimal float library routines. 42882 (line 206) 42883* __dpd_floatsidd: Decimal float library routines. 42884 (line 195) 42885* __dpd_floatsisd: Decimal float library routines. 42886 (line 193) 42887* __dpd_floatsitd: Decimal float library routines. 42888 (line 197) 42889* __dpd_floatunsdidd: Decimal float library routines. 42890 (line 222) 42891* __dpd_floatunsdisd: Decimal float library routines. 42892 (line 220) 42893* __dpd_floatunsditd: Decimal float library routines. 42894 (line 224) 42895* __dpd_floatunssidd: Decimal float library routines. 42896 (line 213) 42897* __dpd_floatunssisd: Decimal float library routines. 42898 (line 211) 42899* __dpd_floatunssitd: Decimal float library routines. 42900 (line 215) 42901* __dpd_gedd2: Decimal float library routines. 42902 (line 276) 42903* __dpd_gesd2: Decimal float library routines. 42904 (line 274) 42905* __dpd_getd2: Decimal float library routines. 42906 (line 278) 42907* __dpd_gtdd2: Decimal float library routines. 42908 (line 303) 42909* __dpd_gtsd2: Decimal float library routines. 42910 (line 301) 42911* __dpd_gttd2: Decimal float library routines. 42912 (line 305) 42913* __dpd_ledd2: Decimal float library routines. 42914 (line 294) 42915* __dpd_lesd2: Decimal float library routines. 42916 (line 292) 42917* __dpd_letd2: Decimal float library routines. 42918 (line 296) 42919* __dpd_ltdd2: Decimal float library routines. 42920 (line 285) 42921* __dpd_ltsd2: Decimal float library routines. 42922 (line 283) 42923* __dpd_lttd2: Decimal float library routines. 42924 (line 287) 42925* __dpd_muldd3: Decimal float library routines. 42926 (line 52) 42927* __dpd_mulsd3: Decimal float library routines. 42928 (line 48) 42929* __dpd_multd3: Decimal float library routines. 42930 (line 56) 42931* __dpd_nedd2: Decimal float library routines. 42932 (line 267) 42933* __dpd_negdd2: Decimal float library routines. 42934 (line 77) 42935* __dpd_negsd2: Decimal float library routines. 42936 (line 75) 42937* __dpd_negtd2: Decimal float library routines. 42938 (line 79) 42939* __dpd_nesd2: Decimal float library routines. 42940 (line 265) 42941* __dpd_netd2: Decimal float library routines. 42942 (line 269) 42943* __dpd_subdd3: Decimal float library routines. 42944 (line 37) 42945* __dpd_subsd3: Decimal float library routines. 42946 (line 33) 42947* __dpd_subtd3: Decimal float library routines. 42948 (line 41) 42949* __dpd_truncdddf: Decimal float library routines. 42950 (line 152) 42951* __dpd_truncddsd2: Decimal float library routines. 42952 (line 93) 42953* __dpd_truncddsf: Decimal float library routines. 42954 (line 123) 42955* __dpd_truncdfsd: Decimal float library routines. 42956 (line 110) 42957* __dpd_truncsdsf: Decimal float library routines. 42958 (line 150) 42959* __dpd_trunctddd2: Decimal float library routines. 42960 (line 97) 42961* __dpd_trunctddf: Decimal float library routines. 42962 (line 129) 42963* __dpd_trunctdsd2: Decimal float library routines. 42964 (line 95) 42965* __dpd_trunctdsf: Decimal float library routines. 42966 (line 125) 42967* __dpd_trunctdtf: Decimal float library routines. 42968 (line 154) 42969* __dpd_trunctdxf: Decimal float library routines. 42970 (line 135) 42971* __dpd_trunctfdd: Decimal float library routines. 42972 (line 118) 42973* __dpd_trunctfsd: Decimal float library routines. 42974 (line 114) 42975* __dpd_truncxfdd: Decimal float library routines. 42976 (line 116) 42977* __dpd_truncxfsd: Decimal float library routines. 42978 (line 112) 42979* __dpd_unorddd2: Decimal float library routines. 42980 (line 234) 42981* __dpd_unordsd2: Decimal float library routines. 42982 (line 232) 42983* __dpd_unordtd2: Decimal float library routines. 42984 (line 236) 42985* __DTOR_LIST__: Initialization. (line 25) 42986* __eqdf2: Soft float library routines. 42987 (line 194) 42988* __eqsf2: Soft float library routines. 42989 (line 193) 42990* __eqtf2: Soft float library routines. 42991 (line 195) 42992* __extenddftf2: Soft float library routines. 42993 (line 68) 42994* __extenddfxf2: Soft float library routines. 42995 (line 69) 42996* __extendsfdf2: Soft float library routines. 42997 (line 65) 42998* __extendsftf2: Soft float library routines. 42999 (line 66) 43000* __extendsfxf2: Soft float library routines. 43001 (line 67) 43002* __ffsdi2: Integer library routines. 43003 (line 144) 43004* __ffsti2: Integer library routines. 43005 (line 145) 43006* __fixdfdi: Soft float library routines. 43007 (line 88) 43008* __fixdfsi: Soft float library routines. 43009 (line 81) 43010* __fixdfti: Soft float library routines. 43011 (line 94) 43012* __fixsfdi: Soft float library routines. 43013 (line 87) 43014* __fixsfsi: Soft float library routines. 43015 (line 80) 43016* __fixsfti: Soft float library routines. 43017 (line 93) 43018* __fixtfdi: Soft float library routines. 43019 (line 89) 43020* __fixtfsi: Soft float library routines. 43021 (line 82) 43022* __fixtfti: Soft float library routines. 43023 (line 95) 43024* __fixunsdfdi: Soft float library routines. 43025 (line 108) 43026* __fixunsdfsi: Soft float library routines. 43027 (line 101) 43028* __fixunsdfti: Soft float library routines. 43029 (line 115) 43030* __fixunssfdi: Soft float library routines. 43031 (line 107) 43032* __fixunssfsi: Soft float library routines. 43033 (line 100) 43034* __fixunssfti: Soft float library routines. 43035 (line 114) 43036* __fixunstfdi: Soft float library routines. 43037 (line 109) 43038* __fixunstfsi: Soft float library routines. 43039 (line 102) 43040* __fixunstfti: Soft float library routines. 43041 (line 116) 43042* __fixunsxfdi: Soft float library routines. 43043 (line 110) 43044* __fixunsxfsi: Soft float library routines. 43045 (line 103) 43046* __fixunsxfti: Soft float library routines. 43047 (line 117) 43048* __fixxfdi: Soft float library routines. 43049 (line 90) 43050* __fixxfsi: Soft float library routines. 43051 (line 83) 43052* __fixxfti: Soft float library routines. 43053 (line 96) 43054* __floatdidf: Soft float library routines. 43055 (line 128) 43056* __floatdisf: Soft float library routines. 43057 (line 127) 43058* __floatditf: Soft float library routines. 43059 (line 129) 43060* __floatdixf: Soft float library routines. 43061 (line 130) 43062* __floatsidf: Soft float library routines. 43063 (line 122) 43064* __floatsisf: Soft float library routines. 43065 (line 121) 43066* __floatsitf: Soft float library routines. 43067 (line 123) 43068* __floatsixf: Soft float library routines. 43069 (line 124) 43070* __floattidf: Soft float library routines. 43071 (line 134) 43072* __floattisf: Soft float library routines. 43073 (line 133) 43074* __floattitf: Soft float library routines. 43075 (line 135) 43076* __floattixf: Soft float library routines. 43077 (line 136) 43078* __floatundidf: Soft float library routines. 43079 (line 146) 43080* __floatundisf: Soft float library routines. 43081 (line 145) 43082* __floatunditf: Soft float library routines. 43083 (line 147) 43084* __floatundixf: Soft float library routines. 43085 (line 148) 43086* __floatunsidf: Soft float library routines. 43087 (line 140) 43088* __floatunsisf: Soft float library routines. 43089 (line 139) 43090* __floatunsitf: Soft float library routines. 43091 (line 141) 43092* __floatunsixf: Soft float library routines. 43093 (line 142) 43094* __floatuntidf: Soft float library routines. 43095 (line 152) 43096* __floatuntisf: Soft float library routines. 43097 (line 151) 43098* __floatuntitf: Soft float library routines. 43099 (line 153) 43100* __floatuntixf: Soft float library routines. 43101 (line 154) 43102* __fractdadf: Fixed-point fractional library routines. 43103 (line 636) 43104* __fractdadi: Fixed-point fractional library routines. 43105 (line 633) 43106* __fractdadq: Fixed-point fractional library routines. 43107 (line 616) 43108* __fractdaha2: Fixed-point fractional library routines. 43109 (line 617) 43110* __fractdahi: Fixed-point fractional library routines. 43111 (line 631) 43112* __fractdahq: Fixed-point fractional library routines. 43113 (line 614) 43114* __fractdaqi: Fixed-point fractional library routines. 43115 (line 630) 43116* __fractdaqq: Fixed-point fractional library routines. 43117 (line 613) 43118* __fractdasa2: Fixed-point fractional library routines. 43119 (line 618) 43120* __fractdasf: Fixed-point fractional library routines. 43121 (line 635) 43122* __fractdasi: Fixed-point fractional library routines. 43123 (line 632) 43124* __fractdasq: Fixed-point fractional library routines. 43125 (line 615) 43126* __fractdata2: Fixed-point fractional library routines. 43127 (line 619) 43128* __fractdati: Fixed-point fractional library routines. 43129 (line 634) 43130* __fractdauda: Fixed-point fractional library routines. 43131 (line 627) 43132* __fractdaudq: Fixed-point fractional library routines. 43133 (line 624) 43134* __fractdauha: Fixed-point fractional library routines. 43135 (line 625) 43136* __fractdauhq: Fixed-point fractional library routines. 43137 (line 621) 43138* __fractdauqq: Fixed-point fractional library routines. 43139 (line 620) 43140* __fractdausa: Fixed-point fractional library routines. 43141 (line 626) 43142* __fractdausq: Fixed-point fractional library routines. 43143 (line 622) 43144* __fractdauta: Fixed-point fractional library routines. 43145 (line 629) 43146* __fractdfda: Fixed-point fractional library routines. 43147 (line 1025) 43148* __fractdfdq: Fixed-point fractional library routines. 43149 (line 1022) 43150* __fractdfha: Fixed-point fractional library routines. 43151 (line 1023) 43152* __fractdfhq: Fixed-point fractional library routines. 43153 (line 1020) 43154* __fractdfqq: Fixed-point fractional library routines. 43155 (line 1019) 43156* __fractdfsa: Fixed-point fractional library routines. 43157 (line 1024) 43158* __fractdfsq: Fixed-point fractional library routines. 43159 (line 1021) 43160* __fractdfta: Fixed-point fractional library routines. 43161 (line 1026) 43162* __fractdfuda: Fixed-point fractional library routines. 43163 (line 1033) 43164* __fractdfudq: Fixed-point fractional library routines. 43165 (line 1030) 43166* __fractdfuha: Fixed-point fractional library routines. 43167 (line 1031) 43168* __fractdfuhq: Fixed-point fractional library routines. 43169 (line 1028) 43170* __fractdfuqq: Fixed-point fractional library routines. 43171 (line 1027) 43172* __fractdfusa: Fixed-point fractional library routines. 43173 (line 1032) 43174* __fractdfusq: Fixed-point fractional library routines. 43175 (line 1029) 43176* __fractdfuta: Fixed-point fractional library routines. 43177 (line 1034) 43178* __fractdida: Fixed-point fractional library routines. 43179 (line 975) 43180* __fractdidq: Fixed-point fractional library routines. 43181 (line 972) 43182* __fractdiha: Fixed-point fractional library routines. 43183 (line 973) 43184* __fractdihq: Fixed-point fractional library routines. 43185 (line 970) 43186* __fractdiqq: Fixed-point fractional library routines. 43187 (line 969) 43188* __fractdisa: Fixed-point fractional library routines. 43189 (line 974) 43190* __fractdisq: Fixed-point fractional library routines. 43191 (line 971) 43192* __fractdita: Fixed-point fractional library routines. 43193 (line 976) 43194* __fractdiuda: Fixed-point fractional library routines. 43195 (line 983) 43196* __fractdiudq: Fixed-point fractional library routines. 43197 (line 980) 43198* __fractdiuha: Fixed-point fractional library routines. 43199 (line 981) 43200* __fractdiuhq: Fixed-point fractional library routines. 43201 (line 978) 43202* __fractdiuqq: Fixed-point fractional library routines. 43203 (line 977) 43204* __fractdiusa: Fixed-point fractional library routines. 43205 (line 982) 43206* __fractdiusq: Fixed-point fractional library routines. 43207 (line 979) 43208* __fractdiuta: Fixed-point fractional library routines. 43209 (line 984) 43210* __fractdqda: Fixed-point fractional library routines. 43211 (line 544) 43212* __fractdqdf: Fixed-point fractional library routines. 43213 (line 566) 43214* __fractdqdi: Fixed-point fractional library routines. 43215 (line 563) 43216* __fractdqha: Fixed-point fractional library routines. 43217 (line 542) 43218* __fractdqhi: Fixed-point fractional library routines. 43219 (line 561) 43220* __fractdqhq2: Fixed-point fractional library routines. 43221 (line 540) 43222* __fractdqqi: Fixed-point fractional library routines. 43223 (line 560) 43224* __fractdqqq2: Fixed-point fractional library routines. 43225 (line 539) 43226* __fractdqsa: Fixed-point fractional library routines. 43227 (line 543) 43228* __fractdqsf: Fixed-point fractional library routines. 43229 (line 565) 43230* __fractdqsi: Fixed-point fractional library routines. 43231 (line 562) 43232* __fractdqsq2: Fixed-point fractional library routines. 43233 (line 541) 43234* __fractdqta: Fixed-point fractional library routines. 43235 (line 545) 43236* __fractdqti: Fixed-point fractional library routines. 43237 (line 564) 43238* __fractdquda: Fixed-point fractional library routines. 43239 (line 557) 43240* __fractdqudq: Fixed-point fractional library routines. 43241 (line 552) 43242* __fractdquha: Fixed-point fractional library routines. 43243 (line 554) 43244* __fractdquhq: Fixed-point fractional library routines. 43245 (line 548) 43246* __fractdquqq: Fixed-point fractional library routines. 43247 (line 547) 43248* __fractdqusa: Fixed-point fractional library routines. 43249 (line 555) 43250* __fractdqusq: Fixed-point fractional library routines. 43251 (line 550) 43252* __fractdquta: Fixed-point fractional library routines. 43253 (line 559) 43254* __fracthada2: Fixed-point fractional library routines. 43255 (line 572) 43256* __fracthadf: Fixed-point fractional library routines. 43257 (line 590) 43258* __fracthadi: Fixed-point fractional library routines. 43259 (line 587) 43260* __fracthadq: Fixed-point fractional library routines. 43261 (line 570) 43262* __fracthahi: Fixed-point fractional library routines. 43263 (line 585) 43264* __fracthahq: Fixed-point fractional library routines. 43265 (line 568) 43266* __fracthaqi: Fixed-point fractional library routines. 43267 (line 584) 43268* __fracthaqq: Fixed-point fractional library routines. 43269 (line 567) 43270* __fracthasa2: Fixed-point fractional library routines. 43271 (line 571) 43272* __fracthasf: Fixed-point fractional library routines. 43273 (line 589) 43274* __fracthasi: Fixed-point fractional library routines. 43275 (line 586) 43276* __fracthasq: Fixed-point fractional library routines. 43277 (line 569) 43278* __fracthata2: Fixed-point fractional library routines. 43279 (line 573) 43280* __fracthati: Fixed-point fractional library routines. 43281 (line 588) 43282* __fracthauda: Fixed-point fractional library routines. 43283 (line 581) 43284* __fracthaudq: Fixed-point fractional library routines. 43285 (line 578) 43286* __fracthauha: Fixed-point fractional library routines. 43287 (line 579) 43288* __fracthauhq: Fixed-point fractional library routines. 43289 (line 575) 43290* __fracthauqq: Fixed-point fractional library routines. 43291 (line 574) 43292* __fracthausa: Fixed-point fractional library routines. 43293 (line 580) 43294* __fracthausq: Fixed-point fractional library routines. 43295 (line 576) 43296* __fracthauta: Fixed-point fractional library routines. 43297 (line 583) 43298* __fracthida: Fixed-point fractional library routines. 43299 (line 943) 43300* __fracthidq: Fixed-point fractional library routines. 43301 (line 940) 43302* __fracthiha: Fixed-point fractional library routines. 43303 (line 941) 43304* __fracthihq: Fixed-point fractional library routines. 43305 (line 938) 43306* __fracthiqq: Fixed-point fractional library routines. 43307 (line 937) 43308* __fracthisa: Fixed-point fractional library routines. 43309 (line 942) 43310* __fracthisq: Fixed-point fractional library routines. 43311 (line 939) 43312* __fracthita: Fixed-point fractional library routines. 43313 (line 944) 43314* __fracthiuda: Fixed-point fractional library routines. 43315 (line 951) 43316* __fracthiudq: Fixed-point fractional library routines. 43317 (line 948) 43318* __fracthiuha: Fixed-point fractional library routines. 43319 (line 949) 43320* __fracthiuhq: Fixed-point fractional library routines. 43321 (line 946) 43322* __fracthiuqq: Fixed-point fractional library routines. 43323 (line 945) 43324* __fracthiusa: Fixed-point fractional library routines. 43325 (line 950) 43326* __fracthiusq: Fixed-point fractional library routines. 43327 (line 947) 43328* __fracthiuta: Fixed-point fractional library routines. 43329 (line 952) 43330* __fracthqda: Fixed-point fractional library routines. 43331 (line 498) 43332* __fracthqdf: Fixed-point fractional library routines. 43333 (line 514) 43334* __fracthqdi: Fixed-point fractional library routines. 43335 (line 511) 43336* __fracthqdq2: Fixed-point fractional library routines. 43337 (line 495) 43338* __fracthqha: Fixed-point fractional library routines. 43339 (line 496) 43340* __fracthqhi: Fixed-point fractional library routines. 43341 (line 509) 43342* __fracthqqi: Fixed-point fractional library routines. 43343 (line 508) 43344* __fracthqqq2: Fixed-point fractional library routines. 43345 (line 493) 43346* __fracthqsa: Fixed-point fractional library routines. 43347 (line 497) 43348* __fracthqsf: Fixed-point fractional library routines. 43349 (line 513) 43350* __fracthqsi: Fixed-point fractional library routines. 43351 (line 510) 43352* __fracthqsq2: Fixed-point fractional library routines. 43353 (line 494) 43354* __fracthqta: Fixed-point fractional library routines. 43355 (line 499) 43356* __fracthqti: Fixed-point fractional library routines. 43357 (line 512) 43358* __fracthquda: Fixed-point fractional library routines. 43359 (line 506) 43360* __fracthqudq: Fixed-point fractional library routines. 43361 (line 503) 43362* __fracthquha: Fixed-point fractional library routines. 43363 (line 504) 43364* __fracthquhq: Fixed-point fractional library routines. 43365 (line 501) 43366* __fracthquqq: Fixed-point fractional library routines. 43367 (line 500) 43368* __fracthqusa: Fixed-point fractional library routines. 43369 (line 505) 43370* __fracthqusq: Fixed-point fractional library routines. 43371 (line 502) 43372* __fracthquta: Fixed-point fractional library routines. 43373 (line 507) 43374* __fractqida: Fixed-point fractional library routines. 43375 (line 925) 43376* __fractqidq: Fixed-point fractional library routines. 43377 (line 922) 43378* __fractqiha: Fixed-point fractional library routines. 43379 (line 923) 43380* __fractqihq: Fixed-point fractional library routines. 43381 (line 920) 43382* __fractqiqq: Fixed-point fractional library routines. 43383 (line 919) 43384* __fractqisa: Fixed-point fractional library routines. 43385 (line 924) 43386* __fractqisq: Fixed-point fractional library routines. 43387 (line 921) 43388* __fractqita: Fixed-point fractional library routines. 43389 (line 926) 43390* __fractqiuda: Fixed-point fractional library routines. 43391 (line 934) 43392* __fractqiudq: Fixed-point fractional library routines. 43393 (line 931) 43394* __fractqiuha: Fixed-point fractional library routines. 43395 (line 932) 43396* __fractqiuhq: Fixed-point fractional library routines. 43397 (line 928) 43398* __fractqiuqq: Fixed-point fractional library routines. 43399 (line 927) 43400* __fractqiusa: Fixed-point fractional library routines. 43401 (line 933) 43402* __fractqiusq: Fixed-point fractional library routines. 43403 (line 929) 43404* __fractqiuta: Fixed-point fractional library routines. 43405 (line 936) 43406* __fractqqda: Fixed-point fractional library routines. 43407 (line 474) 43408* __fractqqdf: Fixed-point fractional library routines. 43409 (line 492) 43410* __fractqqdi: Fixed-point fractional library routines. 43411 (line 489) 43412* __fractqqdq2: Fixed-point fractional library routines. 43413 (line 471) 43414* __fractqqha: Fixed-point fractional library routines. 43415 (line 472) 43416* __fractqqhi: Fixed-point fractional library routines. 43417 (line 487) 43418* __fractqqhq2: Fixed-point fractional library routines. 43419 (line 469) 43420* __fractqqqi: Fixed-point fractional library routines. 43421 (line 486) 43422* __fractqqsa: Fixed-point fractional library routines. 43423 (line 473) 43424* __fractqqsf: Fixed-point fractional library routines. 43425 (line 491) 43426* __fractqqsi: Fixed-point fractional library routines. 43427 (line 488) 43428* __fractqqsq2: Fixed-point fractional library routines. 43429 (line 470) 43430* __fractqqta: Fixed-point fractional library routines. 43431 (line 475) 43432* __fractqqti: Fixed-point fractional library routines. 43433 (line 490) 43434* __fractqquda: Fixed-point fractional library routines. 43435 (line 483) 43436* __fractqqudq: Fixed-point fractional library routines. 43437 (line 480) 43438* __fractqquha: Fixed-point fractional library routines. 43439 (line 481) 43440* __fractqquhq: Fixed-point fractional library routines. 43441 (line 477) 43442* __fractqquqq: Fixed-point fractional library routines. 43443 (line 476) 43444* __fractqqusa: Fixed-point fractional library routines. 43445 (line 482) 43446* __fractqqusq: Fixed-point fractional library routines. 43447 (line 478) 43448* __fractqquta: Fixed-point fractional library routines. 43449 (line 485) 43450* __fractsada2: Fixed-point fractional library routines. 43451 (line 596) 43452* __fractsadf: Fixed-point fractional library routines. 43453 (line 612) 43454* __fractsadi: Fixed-point fractional library routines. 43455 (line 609) 43456* __fractsadq: Fixed-point fractional library routines. 43457 (line 594) 43458* __fractsaha2: Fixed-point fractional library routines. 43459 (line 595) 43460* __fractsahi: Fixed-point fractional library routines. 43461 (line 607) 43462* __fractsahq: Fixed-point fractional library routines. 43463 (line 592) 43464* __fractsaqi: Fixed-point fractional library routines. 43465 (line 606) 43466* __fractsaqq: Fixed-point fractional library routines. 43467 (line 591) 43468* __fractsasf: Fixed-point fractional library routines. 43469 (line 611) 43470* __fractsasi: Fixed-point fractional library routines. 43471 (line 608) 43472* __fractsasq: Fixed-point fractional library routines. 43473 (line 593) 43474* __fractsata2: Fixed-point fractional library routines. 43475 (line 597) 43476* __fractsati: Fixed-point fractional library routines. 43477 (line 610) 43478* __fractsauda: Fixed-point fractional library routines. 43479 (line 604) 43480* __fractsaudq: Fixed-point fractional library routines. 43481 (line 601) 43482* __fractsauha: Fixed-point fractional library routines. 43483 (line 602) 43484* __fractsauhq: Fixed-point fractional library routines. 43485 (line 599) 43486* __fractsauqq: Fixed-point fractional library routines. 43487 (line 598) 43488* __fractsausa: Fixed-point fractional library routines. 43489 (line 603) 43490* __fractsausq: Fixed-point fractional library routines. 43491 (line 600) 43492* __fractsauta: Fixed-point fractional library routines. 43493 (line 605) 43494* __fractsfda: Fixed-point fractional library routines. 43495 (line 1009) 43496* __fractsfdq: Fixed-point fractional library routines. 43497 (line 1006) 43498* __fractsfha: Fixed-point fractional library routines. 43499 (line 1007) 43500* __fractsfhq: Fixed-point fractional library routines. 43501 (line 1004) 43502* __fractsfqq: Fixed-point fractional library routines. 43503 (line 1003) 43504* __fractsfsa: Fixed-point fractional library routines. 43505 (line 1008) 43506* __fractsfsq: Fixed-point fractional library routines. 43507 (line 1005) 43508* __fractsfta: Fixed-point fractional library routines. 43509 (line 1010) 43510* __fractsfuda: Fixed-point fractional library routines. 43511 (line 1017) 43512* __fractsfudq: Fixed-point fractional library routines. 43513 (line 1014) 43514* __fractsfuha: Fixed-point fractional library routines. 43515 (line 1015) 43516* __fractsfuhq: Fixed-point fractional library routines. 43517 (line 1012) 43518* __fractsfuqq: Fixed-point fractional library routines. 43519 (line 1011) 43520* __fractsfusa: Fixed-point fractional library routines. 43521 (line 1016) 43522* __fractsfusq: Fixed-point fractional library routines. 43523 (line 1013) 43524* __fractsfuta: Fixed-point fractional library routines. 43525 (line 1018) 43526* __fractsida: Fixed-point fractional library routines. 43527 (line 959) 43528* __fractsidq: Fixed-point fractional library routines. 43529 (line 956) 43530* __fractsiha: Fixed-point fractional library routines. 43531 (line 957) 43532* __fractsihq: Fixed-point fractional library routines. 43533 (line 954) 43534* __fractsiqq: Fixed-point fractional library routines. 43535 (line 953) 43536* __fractsisa: Fixed-point fractional library routines. 43537 (line 958) 43538* __fractsisq: Fixed-point fractional library routines. 43539 (line 955) 43540* __fractsita: Fixed-point fractional library routines. 43541 (line 960) 43542* __fractsiuda: Fixed-point fractional library routines. 43543 (line 967) 43544* __fractsiudq: Fixed-point fractional library routines. 43545 (line 964) 43546* __fractsiuha: Fixed-point fractional library routines. 43547 (line 965) 43548* __fractsiuhq: Fixed-point fractional library routines. 43549 (line 962) 43550* __fractsiuqq: Fixed-point fractional library routines. 43551 (line 961) 43552* __fractsiusa: Fixed-point fractional library routines. 43553 (line 966) 43554* __fractsiusq: Fixed-point fractional library routines. 43555 (line 963) 43556* __fractsiuta: Fixed-point fractional library routines. 43557 (line 968) 43558* __fractsqda: Fixed-point fractional library routines. 43559 (line 520) 43560* __fractsqdf: Fixed-point fractional library routines. 43561 (line 538) 43562* __fractsqdi: Fixed-point fractional library routines. 43563 (line 535) 43564* __fractsqdq2: Fixed-point fractional library routines. 43565 (line 517) 43566* __fractsqha: Fixed-point fractional library routines. 43567 (line 518) 43568* __fractsqhi: Fixed-point fractional library routines. 43569 (line 533) 43570* __fractsqhq2: Fixed-point fractional library routines. 43571 (line 516) 43572* __fractsqqi: Fixed-point fractional library routines. 43573 (line 532) 43574* __fractsqqq2: Fixed-point fractional library routines. 43575 (line 515) 43576* __fractsqsa: Fixed-point fractional library routines. 43577 (line 519) 43578* __fractsqsf: Fixed-point fractional library routines. 43579 (line 537) 43580* __fractsqsi: Fixed-point fractional library routines. 43581 (line 534) 43582* __fractsqta: Fixed-point fractional library routines. 43583 (line 521) 43584* __fractsqti: Fixed-point fractional library routines. 43585 (line 536) 43586* __fractsquda: Fixed-point fractional library routines. 43587 (line 529) 43588* __fractsqudq: Fixed-point fractional library routines. 43589 (line 526) 43590* __fractsquha: Fixed-point fractional library routines. 43591 (line 527) 43592* __fractsquhq: Fixed-point fractional library routines. 43593 (line 523) 43594* __fractsquqq: Fixed-point fractional library routines. 43595 (line 522) 43596* __fractsqusa: Fixed-point fractional library routines. 43597 (line 528) 43598* __fractsqusq: Fixed-point fractional library routines. 43599 (line 524) 43600* __fractsquta: Fixed-point fractional library routines. 43601 (line 531) 43602* __fracttada2: Fixed-point fractional library routines. 43603 (line 643) 43604* __fracttadf: Fixed-point fractional library routines. 43605 (line 664) 43606* __fracttadi: Fixed-point fractional library routines. 43607 (line 661) 43608* __fracttadq: Fixed-point fractional library routines. 43609 (line 640) 43610* __fracttaha2: Fixed-point fractional library routines. 43611 (line 641) 43612* __fracttahi: Fixed-point fractional library routines. 43613 (line 659) 43614* __fracttahq: Fixed-point fractional library routines. 43615 (line 638) 43616* __fracttaqi: Fixed-point fractional library routines. 43617 (line 658) 43618* __fracttaqq: Fixed-point fractional library routines. 43619 (line 637) 43620* __fracttasa2: Fixed-point fractional library routines. 43621 (line 642) 43622* __fracttasf: Fixed-point fractional library routines. 43623 (line 663) 43624* __fracttasi: Fixed-point fractional library routines. 43625 (line 660) 43626* __fracttasq: Fixed-point fractional library routines. 43627 (line 639) 43628* __fracttati: Fixed-point fractional library routines. 43629 (line 662) 43630* __fracttauda: Fixed-point fractional library routines. 43631 (line 655) 43632* __fracttaudq: Fixed-point fractional library routines. 43633 (line 650) 43634* __fracttauha: Fixed-point fractional library routines. 43635 (line 652) 43636* __fracttauhq: Fixed-point fractional library routines. 43637 (line 646) 43638* __fracttauqq: Fixed-point fractional library routines. 43639 (line 645) 43640* __fracttausa: Fixed-point fractional library routines. 43641 (line 653) 43642* __fracttausq: Fixed-point fractional library routines. 43643 (line 648) 43644* __fracttauta: Fixed-point fractional library routines. 43645 (line 657) 43646* __fracttida: Fixed-point fractional library routines. 43647 (line 991) 43648* __fracttidq: Fixed-point fractional library routines. 43649 (line 988) 43650* __fracttiha: Fixed-point fractional library routines. 43651 (line 989) 43652* __fracttihq: Fixed-point fractional library routines. 43653 (line 986) 43654* __fracttiqq: Fixed-point fractional library routines. 43655 (line 985) 43656* __fracttisa: Fixed-point fractional library routines. 43657 (line 990) 43658* __fracttisq: Fixed-point fractional library routines. 43659 (line 987) 43660* __fracttita: Fixed-point fractional library routines. 43661 (line 992) 43662* __fracttiuda: Fixed-point fractional library routines. 43663 (line 1000) 43664* __fracttiudq: Fixed-point fractional library routines. 43665 (line 997) 43666* __fracttiuha: Fixed-point fractional library routines. 43667 (line 998) 43668* __fracttiuhq: Fixed-point fractional library routines. 43669 (line 994) 43670* __fracttiuqq: Fixed-point fractional library routines. 43671 (line 993) 43672* __fracttiusa: Fixed-point fractional library routines. 43673 (line 999) 43674* __fracttiusq: Fixed-point fractional library routines. 43675 (line 995) 43676* __fracttiuta: Fixed-point fractional library routines. 43677 (line 1002) 43678* __fractudada: Fixed-point fractional library routines. 43679 (line 858) 43680* __fractudadf: Fixed-point fractional library routines. 43681 (line 881) 43682* __fractudadi: Fixed-point fractional library routines. 43683 (line 878) 43684* __fractudadq: Fixed-point fractional library routines. 43685 (line 855) 43686* __fractudaha: Fixed-point fractional library routines. 43687 (line 856) 43688* __fractudahi: Fixed-point fractional library routines. 43689 (line 876) 43690* __fractudahq: Fixed-point fractional library routines. 43691 (line 852) 43692* __fractudaqi: Fixed-point fractional library routines. 43693 (line 875) 43694* __fractudaqq: Fixed-point fractional library routines. 43695 (line 851) 43696* __fractudasa: Fixed-point fractional library routines. 43697 (line 857) 43698* __fractudasf: Fixed-point fractional library routines. 43699 (line 880) 43700* __fractudasi: Fixed-point fractional library routines. 43701 (line 877) 43702* __fractudasq: Fixed-point fractional library routines. 43703 (line 853) 43704* __fractudata: Fixed-point fractional library routines. 43705 (line 860) 43706* __fractudati: Fixed-point fractional library routines. 43707 (line 879) 43708* __fractudaudq: Fixed-point fractional library routines. 43709 (line 868) 43710* __fractudauha2: Fixed-point fractional library routines. 43711 (line 870) 43712* __fractudauhq: Fixed-point fractional library routines. 43713 (line 864) 43714* __fractudauqq: Fixed-point fractional library routines. 43715 (line 862) 43716* __fractudausa2: Fixed-point fractional library routines. 43717 (line 872) 43718* __fractudausq: Fixed-point fractional library routines. 43719 (line 866) 43720* __fractudauta2: Fixed-point fractional library routines. 43721 (line 874) 43722* __fractudqda: Fixed-point fractional library routines. 43723 (line 766) 43724* __fractudqdf: Fixed-point fractional library routines. 43725 (line 791) 43726* __fractudqdi: Fixed-point fractional library routines. 43727 (line 787) 43728* __fractudqdq: Fixed-point fractional library routines. 43729 (line 761) 43730* __fractudqha: Fixed-point fractional library routines. 43731 (line 763) 43732* __fractudqhi: Fixed-point fractional library routines. 43733 (line 785) 43734* __fractudqhq: Fixed-point fractional library routines. 43735 (line 757) 43736* __fractudqqi: Fixed-point fractional library routines. 43737 (line 784) 43738* __fractudqqq: Fixed-point fractional library routines. 43739 (line 756) 43740* __fractudqsa: Fixed-point fractional library routines. 43741 (line 764) 43742* __fractudqsf: Fixed-point fractional library routines. 43743 (line 790) 43744* __fractudqsi: Fixed-point fractional library routines. 43745 (line 786) 43746* __fractudqsq: Fixed-point fractional library routines. 43747 (line 759) 43748* __fractudqta: Fixed-point fractional library routines. 43749 (line 768) 43750* __fractudqti: Fixed-point fractional library routines. 43751 (line 789) 43752* __fractudquda: Fixed-point fractional library routines. 43753 (line 780) 43754* __fractudquha: Fixed-point fractional library routines. 43755 (line 776) 43756* __fractudquhq2: Fixed-point fractional library routines. 43757 (line 772) 43758* __fractudquqq2: Fixed-point fractional library routines. 43759 (line 770) 43760* __fractudqusa: Fixed-point fractional library routines. 43761 (line 778) 43762* __fractudqusq2: Fixed-point fractional library routines. 43763 (line 774) 43764* __fractudquta: Fixed-point fractional library routines. 43765 (line 782) 43766* __fractuhada: Fixed-point fractional library routines. 43767 (line 799) 43768* __fractuhadf: Fixed-point fractional library routines. 43769 (line 822) 43770* __fractuhadi: Fixed-point fractional library routines. 43771 (line 819) 43772* __fractuhadq: Fixed-point fractional library routines. 43773 (line 796) 43774* __fractuhaha: Fixed-point fractional library routines. 43775 (line 797) 43776* __fractuhahi: Fixed-point fractional library routines. 43777 (line 817) 43778* __fractuhahq: Fixed-point fractional library routines. 43779 (line 793) 43780* __fractuhaqi: Fixed-point fractional library routines. 43781 (line 816) 43782* __fractuhaqq: Fixed-point fractional library routines. 43783 (line 792) 43784* __fractuhasa: Fixed-point fractional library routines. 43785 (line 798) 43786* __fractuhasf: Fixed-point fractional library routines. 43787 (line 821) 43788* __fractuhasi: Fixed-point fractional library routines. 43789 (line 818) 43790* __fractuhasq: Fixed-point fractional library routines. 43791 (line 794) 43792* __fractuhata: Fixed-point fractional library routines. 43793 (line 801) 43794* __fractuhati: Fixed-point fractional library routines. 43795 (line 820) 43796* __fractuhauda2: Fixed-point fractional library routines. 43797 (line 813) 43798* __fractuhaudq: Fixed-point fractional library routines. 43799 (line 809) 43800* __fractuhauhq: Fixed-point fractional library routines. 43801 (line 805) 43802* __fractuhauqq: Fixed-point fractional library routines. 43803 (line 803) 43804* __fractuhausa2: Fixed-point fractional library routines. 43805 (line 811) 43806* __fractuhausq: Fixed-point fractional library routines. 43807 (line 807) 43808* __fractuhauta2: Fixed-point fractional library routines. 43809 (line 815) 43810* __fractuhqda: Fixed-point fractional library routines. 43811 (line 702) 43812* __fractuhqdf: Fixed-point fractional library routines. 43813 (line 723) 43814* __fractuhqdi: Fixed-point fractional library routines. 43815 (line 720) 43816* __fractuhqdq: Fixed-point fractional library routines. 43817 (line 699) 43818* __fractuhqha: Fixed-point fractional library routines. 43819 (line 700) 43820* __fractuhqhi: Fixed-point fractional library routines. 43821 (line 718) 43822* __fractuhqhq: Fixed-point fractional library routines. 43823 (line 697) 43824* __fractuhqqi: Fixed-point fractional library routines. 43825 (line 717) 43826* __fractuhqqq: Fixed-point fractional library routines. 43827 (line 696) 43828* __fractuhqsa: Fixed-point fractional library routines. 43829 (line 701) 43830* __fractuhqsf: Fixed-point fractional library routines. 43831 (line 722) 43832* __fractuhqsi: Fixed-point fractional library routines. 43833 (line 719) 43834* __fractuhqsq: Fixed-point fractional library routines. 43835 (line 698) 43836* __fractuhqta: Fixed-point fractional library routines. 43837 (line 703) 43838* __fractuhqti: Fixed-point fractional library routines. 43839 (line 721) 43840* __fractuhquda: Fixed-point fractional library routines. 43841 (line 714) 43842* __fractuhqudq2: Fixed-point fractional library routines. 43843 (line 709) 43844* __fractuhquha: Fixed-point fractional library routines. 43845 (line 711) 43846* __fractuhquqq2: Fixed-point fractional library routines. 43847 (line 705) 43848* __fractuhqusa: Fixed-point fractional library routines. 43849 (line 712) 43850* __fractuhqusq2: Fixed-point fractional library routines. 43851 (line 707) 43852* __fractuhquta: Fixed-point fractional library routines. 43853 (line 716) 43854* __fractunsdadi: Fixed-point fractional library routines. 43855 (line 1555) 43856* __fractunsdahi: Fixed-point fractional library routines. 43857 (line 1553) 43858* __fractunsdaqi: Fixed-point fractional library routines. 43859 (line 1552) 43860* __fractunsdasi: Fixed-point fractional library routines. 43861 (line 1554) 43862* __fractunsdati: Fixed-point fractional library routines. 43863 (line 1556) 43864* __fractunsdida: Fixed-point fractional library routines. 43865 (line 1707) 43866* __fractunsdidq: Fixed-point fractional library routines. 43867 (line 1704) 43868* __fractunsdiha: Fixed-point fractional library routines. 43869 (line 1705) 43870* __fractunsdihq: Fixed-point fractional library routines. 43871 (line 1702) 43872* __fractunsdiqq: Fixed-point fractional library routines. 43873 (line 1701) 43874* __fractunsdisa: Fixed-point fractional library routines. 43875 (line 1706) 43876* __fractunsdisq: Fixed-point fractional library routines. 43877 (line 1703) 43878* __fractunsdita: Fixed-point fractional library routines. 43879 (line 1708) 43880* __fractunsdiuda: Fixed-point fractional library routines. 43881 (line 1720) 43882* __fractunsdiudq: Fixed-point fractional library routines. 43883 (line 1715) 43884* __fractunsdiuha: Fixed-point fractional library routines. 43885 (line 1717) 43886* __fractunsdiuhq: Fixed-point fractional library routines. 43887 (line 1711) 43888* __fractunsdiuqq: Fixed-point fractional library routines. 43889 (line 1710) 43890* __fractunsdiusa: Fixed-point fractional library routines. 43891 (line 1718) 43892* __fractunsdiusq: Fixed-point fractional library routines. 43893 (line 1713) 43894* __fractunsdiuta: Fixed-point fractional library routines. 43895 (line 1722) 43896* __fractunsdqdi: Fixed-point fractional library routines. 43897 (line 1539) 43898* __fractunsdqhi: Fixed-point fractional library routines. 43899 (line 1537) 43900* __fractunsdqqi: Fixed-point fractional library routines. 43901 (line 1536) 43902* __fractunsdqsi: Fixed-point fractional library routines. 43903 (line 1538) 43904* __fractunsdqti: Fixed-point fractional library routines. 43905 (line 1541) 43906* __fractunshadi: Fixed-point fractional library routines. 43907 (line 1545) 43908* __fractunshahi: Fixed-point fractional library routines. 43909 (line 1543) 43910* __fractunshaqi: Fixed-point fractional library routines. 43911 (line 1542) 43912* __fractunshasi: Fixed-point fractional library routines. 43913 (line 1544) 43914* __fractunshati: Fixed-point fractional library routines. 43915 (line 1546) 43916* __fractunshida: Fixed-point fractional library routines. 43917 (line 1663) 43918* __fractunshidq: Fixed-point fractional library routines. 43919 (line 1660) 43920* __fractunshiha: Fixed-point fractional library routines. 43921 (line 1661) 43922* __fractunshihq: Fixed-point fractional library routines. 43923 (line 1658) 43924* __fractunshiqq: Fixed-point fractional library routines. 43925 (line 1657) 43926* __fractunshisa: Fixed-point fractional library routines. 43927 (line 1662) 43928* __fractunshisq: Fixed-point fractional library routines. 43929 (line 1659) 43930* __fractunshita: Fixed-point fractional library routines. 43931 (line 1664) 43932* __fractunshiuda: Fixed-point fractional library routines. 43933 (line 1676) 43934* __fractunshiudq: Fixed-point fractional library routines. 43935 (line 1671) 43936* __fractunshiuha: Fixed-point fractional library routines. 43937 (line 1673) 43938* __fractunshiuhq: Fixed-point fractional library routines. 43939 (line 1667) 43940* __fractunshiuqq: Fixed-point fractional library routines. 43941 (line 1666) 43942* __fractunshiusa: Fixed-point fractional library routines. 43943 (line 1674) 43944* __fractunshiusq: Fixed-point fractional library routines. 43945 (line 1669) 43946* __fractunshiuta: Fixed-point fractional library routines. 43947 (line 1678) 43948* __fractunshqdi: Fixed-point fractional library routines. 43949 (line 1529) 43950* __fractunshqhi: Fixed-point fractional library routines. 43951 (line 1527) 43952* __fractunshqqi: Fixed-point fractional library routines. 43953 (line 1526) 43954* __fractunshqsi: Fixed-point fractional library routines. 43955 (line 1528) 43956* __fractunshqti: Fixed-point fractional library routines. 43957 (line 1530) 43958* __fractunsqida: Fixed-point fractional library routines. 43959 (line 1641) 43960* __fractunsqidq: Fixed-point fractional library routines. 43961 (line 1638) 43962* __fractunsqiha: Fixed-point fractional library routines. 43963 (line 1639) 43964* __fractunsqihq: Fixed-point fractional library routines. 43965 (line 1636) 43966* __fractunsqiqq: Fixed-point fractional library routines. 43967 (line 1635) 43968* __fractunsqisa: Fixed-point fractional library routines. 43969 (line 1640) 43970* __fractunsqisq: Fixed-point fractional library routines. 43971 (line 1637) 43972* __fractunsqita: Fixed-point fractional library routines. 43973 (line 1642) 43974* __fractunsqiuda: Fixed-point fractional library routines. 43975 (line 1654) 43976* __fractunsqiudq: Fixed-point fractional library routines. 43977 (line 1649) 43978* __fractunsqiuha: Fixed-point fractional library routines. 43979 (line 1651) 43980* __fractunsqiuhq: Fixed-point fractional library routines. 43981 (line 1645) 43982* __fractunsqiuqq: Fixed-point fractional library routines. 43983 (line 1644) 43984* __fractunsqiusa: Fixed-point fractional library routines. 43985 (line 1652) 43986* __fractunsqiusq: Fixed-point fractional library routines. 43987 (line 1647) 43988* __fractunsqiuta: Fixed-point fractional library routines. 43989 (line 1656) 43990* __fractunsqqdi: Fixed-point fractional library routines. 43991 (line 1524) 43992* __fractunsqqhi: Fixed-point fractional library routines. 43993 (line 1522) 43994* __fractunsqqqi: Fixed-point fractional library routines. 43995 (line 1521) 43996* __fractunsqqsi: Fixed-point fractional library routines. 43997 (line 1523) 43998* __fractunsqqti: Fixed-point fractional library routines. 43999 (line 1525) 44000* __fractunssadi: Fixed-point fractional library routines. 44001 (line 1550) 44002* __fractunssahi: Fixed-point fractional library routines. 44003 (line 1548) 44004* __fractunssaqi: Fixed-point fractional library routines. 44005 (line 1547) 44006* __fractunssasi: Fixed-point fractional library routines. 44007 (line 1549) 44008* __fractunssati: Fixed-point fractional library routines. 44009 (line 1551) 44010* __fractunssida: Fixed-point fractional library routines. 44011 (line 1685) 44012* __fractunssidq: Fixed-point fractional library routines. 44013 (line 1682) 44014* __fractunssiha: Fixed-point fractional library routines. 44015 (line 1683) 44016* __fractunssihq: Fixed-point fractional library routines. 44017 (line 1680) 44018* __fractunssiqq: Fixed-point fractional library routines. 44019 (line 1679) 44020* __fractunssisa: Fixed-point fractional library routines. 44021 (line 1684) 44022* __fractunssisq: Fixed-point fractional library routines. 44023 (line 1681) 44024* __fractunssita: Fixed-point fractional library routines. 44025 (line 1686) 44026* __fractunssiuda: Fixed-point fractional library routines. 44027 (line 1698) 44028* __fractunssiudq: Fixed-point fractional library routines. 44029 (line 1693) 44030* __fractunssiuha: Fixed-point fractional library routines. 44031 (line 1695) 44032* __fractunssiuhq: Fixed-point fractional library routines. 44033 (line 1689) 44034* __fractunssiuqq: Fixed-point fractional library routines. 44035 (line 1688) 44036* __fractunssiusa: Fixed-point fractional library routines. 44037 (line 1696) 44038* __fractunssiusq: Fixed-point fractional library routines. 44039 (line 1691) 44040* __fractunssiuta: Fixed-point fractional library routines. 44041 (line 1700) 44042* __fractunssqdi: Fixed-point fractional library routines. 44043 (line 1534) 44044* __fractunssqhi: Fixed-point fractional library routines. 44045 (line 1532) 44046* __fractunssqqi: Fixed-point fractional library routines. 44047 (line 1531) 44048* __fractunssqsi: Fixed-point fractional library routines. 44049 (line 1533) 44050* __fractunssqti: Fixed-point fractional library routines. 44051 (line 1535) 44052* __fractunstadi: Fixed-point fractional library routines. 44053 (line 1560) 44054* __fractunstahi: Fixed-point fractional library routines. 44055 (line 1558) 44056* __fractunstaqi: Fixed-point fractional library routines. 44057 (line 1557) 44058* __fractunstasi: Fixed-point fractional library routines. 44059 (line 1559) 44060* __fractunstati: Fixed-point fractional library routines. 44061 (line 1562) 44062* __fractunstida: Fixed-point fractional library routines. 44063 (line 1730) 44064* __fractunstidq: Fixed-point fractional library routines. 44065 (line 1727) 44066* __fractunstiha: Fixed-point fractional library routines. 44067 (line 1728) 44068* __fractunstihq: Fixed-point fractional library routines. 44069 (line 1724) 44070* __fractunstiqq: Fixed-point fractional library routines. 44071 (line 1723) 44072* __fractunstisa: Fixed-point fractional library routines. 44073 (line 1729) 44074* __fractunstisq: Fixed-point fractional library routines. 44075 (line 1725) 44076* __fractunstita: Fixed-point fractional library routines. 44077 (line 1732) 44078* __fractunstiuda: Fixed-point fractional library routines. 44079 (line 1746) 44080* __fractunstiudq: Fixed-point fractional library routines. 44081 (line 1740) 44082* __fractunstiuha: Fixed-point fractional library routines. 44083 (line 1742) 44084* __fractunstiuhq: Fixed-point fractional library routines. 44085 (line 1736) 44086* __fractunstiuqq: Fixed-point fractional library routines. 44087 (line 1734) 44088* __fractunstiusa: Fixed-point fractional library routines. 44089 (line 1744) 44090* __fractunstiusq: Fixed-point fractional library routines. 44091 (line 1738) 44092* __fractunstiuta: Fixed-point fractional library routines. 44093 (line 1748) 44094* __fractunsudadi: Fixed-point fractional library routines. 44095 (line 1622) 44096* __fractunsudahi: Fixed-point fractional library routines. 44097 (line 1618) 44098* __fractunsudaqi: Fixed-point fractional library routines. 44099 (line 1616) 44100* __fractunsudasi: Fixed-point fractional library routines. 44101 (line 1620) 44102* __fractunsudati: Fixed-point fractional library routines. 44103 (line 1624) 44104* __fractunsudqdi: Fixed-point fractional library routines. 44105 (line 1596) 44106* __fractunsudqhi: Fixed-point fractional library routines. 44107 (line 1592) 44108* __fractunsudqqi: Fixed-point fractional library routines. 44109 (line 1590) 44110* __fractunsudqsi: Fixed-point fractional library routines. 44111 (line 1594) 44112* __fractunsudqti: Fixed-point fractional library routines. 44113 (line 1598) 44114* __fractunsuhadi: Fixed-point fractional library routines. 44115 (line 1606) 44116* __fractunsuhahi: Fixed-point fractional library routines. 44117 (line 1602) 44118* __fractunsuhaqi: Fixed-point fractional library routines. 44119 (line 1600) 44120* __fractunsuhasi: Fixed-point fractional library routines. 44121 (line 1604) 44122* __fractunsuhati: Fixed-point fractional library routines. 44123 (line 1608) 44124* __fractunsuhqdi: Fixed-point fractional library routines. 44125 (line 1576) 44126* __fractunsuhqhi: Fixed-point fractional library routines. 44127 (line 1574) 44128* __fractunsuhqqi: Fixed-point fractional library routines. 44129 (line 1573) 44130* __fractunsuhqsi: Fixed-point fractional library routines. 44131 (line 1575) 44132* __fractunsuhqti: Fixed-point fractional library routines. 44133 (line 1578) 44134* __fractunsuqqdi: Fixed-point fractional library routines. 44135 (line 1570) 44136* __fractunsuqqhi: Fixed-point fractional library routines. 44137 (line 1566) 44138* __fractunsuqqqi: Fixed-point fractional library routines. 44139 (line 1564) 44140* __fractunsuqqsi: Fixed-point fractional library routines. 44141 (line 1568) 44142* __fractunsuqqti: Fixed-point fractional library routines. 44143 (line 1572) 44144* __fractunsusadi: Fixed-point fractional library routines. 44145 (line 1612) 44146* __fractunsusahi: Fixed-point fractional library routines. 44147 (line 1610) 44148* __fractunsusaqi: Fixed-point fractional library routines. 44149 (line 1609) 44150* __fractunsusasi: Fixed-point fractional library routines. 44151 (line 1611) 44152* __fractunsusati: Fixed-point fractional library routines. 44153 (line 1614) 44154* __fractunsusqdi: Fixed-point fractional library routines. 44155 (line 1586) 44156* __fractunsusqhi: Fixed-point fractional library routines. 44157 (line 1582) 44158* __fractunsusqqi: Fixed-point fractional library routines. 44159 (line 1580) 44160* __fractunsusqsi: Fixed-point fractional library routines. 44161 (line 1584) 44162* __fractunsusqti: Fixed-point fractional library routines. 44163 (line 1588) 44164* __fractunsutadi: Fixed-point fractional library routines. 44165 (line 1632) 44166* __fractunsutahi: Fixed-point fractional library routines. 44167 (line 1628) 44168* __fractunsutaqi: Fixed-point fractional library routines. 44169 (line 1626) 44170* __fractunsutasi: Fixed-point fractional library routines. 44171 (line 1630) 44172* __fractunsutati: Fixed-point fractional library routines. 44173 (line 1634) 44174* __fractuqqda: Fixed-point fractional library routines. 44175 (line 672) 44176* __fractuqqdf: Fixed-point fractional library routines. 44177 (line 695) 44178* __fractuqqdi: Fixed-point fractional library routines. 44179 (line 692) 44180* __fractuqqdq: Fixed-point fractional library routines. 44181 (line 669) 44182* __fractuqqha: Fixed-point fractional library routines. 44183 (line 670) 44184* __fractuqqhi: Fixed-point fractional library routines. 44185 (line 690) 44186* __fractuqqhq: Fixed-point fractional library routines. 44187 (line 666) 44188* __fractuqqqi: Fixed-point fractional library routines. 44189 (line 689) 44190* __fractuqqqq: Fixed-point fractional library routines. 44191 (line 665) 44192* __fractuqqsa: Fixed-point fractional library routines. 44193 (line 671) 44194* __fractuqqsf: Fixed-point fractional library routines. 44195 (line 694) 44196* __fractuqqsi: Fixed-point fractional library routines. 44197 (line 691) 44198* __fractuqqsq: Fixed-point fractional library routines. 44199 (line 667) 44200* __fractuqqta: Fixed-point fractional library routines. 44201 (line 674) 44202* __fractuqqti: Fixed-point fractional library routines. 44203 (line 693) 44204* __fractuqquda: Fixed-point fractional library routines. 44205 (line 686) 44206* __fractuqqudq2: Fixed-point fractional library routines. 44207 (line 680) 44208* __fractuqquha: Fixed-point fractional library routines. 44209 (line 682) 44210* __fractuqquhq2: Fixed-point fractional library routines. 44211 (line 676) 44212* __fractuqqusa: Fixed-point fractional library routines. 44213 (line 684) 44214* __fractuqqusq2: Fixed-point fractional library routines. 44215 (line 678) 44216* __fractuqquta: Fixed-point fractional library routines. 44217 (line 688) 44218* __fractusada: Fixed-point fractional library routines. 44219 (line 829) 44220* __fractusadf: Fixed-point fractional library routines. 44221 (line 850) 44222* __fractusadi: Fixed-point fractional library routines. 44223 (line 847) 44224* __fractusadq: Fixed-point fractional library routines. 44225 (line 826) 44226* __fractusaha: Fixed-point fractional library routines. 44227 (line 827) 44228* __fractusahi: Fixed-point fractional library routines. 44229 (line 845) 44230* __fractusahq: Fixed-point fractional library routines. 44231 (line 824) 44232* __fractusaqi: Fixed-point fractional library routines. 44233 (line 844) 44234* __fractusaqq: Fixed-point fractional library routines. 44235 (line 823) 44236* __fractusasa: Fixed-point fractional library routines. 44237 (line 828) 44238* __fractusasf: Fixed-point fractional library routines. 44239 (line 849) 44240* __fractusasi: Fixed-point fractional library routines. 44241 (line 846) 44242* __fractusasq: Fixed-point fractional library routines. 44243 (line 825) 44244* __fractusata: Fixed-point fractional library routines. 44245 (line 830) 44246* __fractusati: Fixed-point fractional library routines. 44247 (line 848) 44248* __fractusauda2: Fixed-point fractional library routines. 44249 (line 841) 44250* __fractusaudq: Fixed-point fractional library routines. 44251 (line 837) 44252* __fractusauha2: Fixed-point fractional library routines. 44253 (line 839) 44254* __fractusauhq: Fixed-point fractional library routines. 44255 (line 833) 44256* __fractusauqq: Fixed-point fractional library routines. 44257 (line 832) 44258* __fractusausq: Fixed-point fractional library routines. 44259 (line 835) 44260* __fractusauta2: Fixed-point fractional library routines. 44261 (line 843) 44262* __fractusqda: Fixed-point fractional library routines. 44263 (line 731) 44264* __fractusqdf: Fixed-point fractional library routines. 44265 (line 754) 44266* __fractusqdi: Fixed-point fractional library routines. 44267 (line 751) 44268* __fractusqdq: Fixed-point fractional library routines. 44269 (line 728) 44270* __fractusqha: Fixed-point fractional library routines. 44271 (line 729) 44272* __fractusqhi: Fixed-point fractional library routines. 44273 (line 749) 44274* __fractusqhq: Fixed-point fractional library routines. 44275 (line 725) 44276* __fractusqqi: Fixed-point fractional library routines. 44277 (line 748) 44278* __fractusqqq: Fixed-point fractional library routines. 44279 (line 724) 44280* __fractusqsa: Fixed-point fractional library routines. 44281 (line 730) 44282* __fractusqsf: Fixed-point fractional library routines. 44283 (line 753) 44284* __fractusqsi: Fixed-point fractional library routines. 44285 (line 750) 44286* __fractusqsq: Fixed-point fractional library routines. 44287 (line 726) 44288* __fractusqta: Fixed-point fractional library routines. 44289 (line 733) 44290* __fractusqti: Fixed-point fractional library routines. 44291 (line 752) 44292* __fractusquda: Fixed-point fractional library routines. 44293 (line 745) 44294* __fractusqudq2: Fixed-point fractional library routines. 44295 (line 739) 44296* __fractusquha: Fixed-point fractional library routines. 44297 (line 741) 44298* __fractusquhq2: Fixed-point fractional library routines. 44299 (line 737) 44300* __fractusquqq2: Fixed-point fractional library routines. 44301 (line 735) 44302* __fractusqusa: Fixed-point fractional library routines. 44303 (line 743) 44304* __fractusquta: Fixed-point fractional library routines. 44305 (line 747) 44306* __fractutada: Fixed-point fractional library routines. 44307 (line 893) 44308* __fractutadf: Fixed-point fractional library routines. 44309 (line 918) 44310* __fractutadi: Fixed-point fractional library routines. 44311 (line 914) 44312* __fractutadq: Fixed-point fractional library routines. 44313 (line 888) 44314* __fractutaha: Fixed-point fractional library routines. 44315 (line 890) 44316* __fractutahi: Fixed-point fractional library routines. 44317 (line 912) 44318* __fractutahq: Fixed-point fractional library routines. 44319 (line 884) 44320* __fractutaqi: Fixed-point fractional library routines. 44321 (line 911) 44322* __fractutaqq: Fixed-point fractional library routines. 44323 (line 883) 44324* __fractutasa: Fixed-point fractional library routines. 44325 (line 891) 44326* __fractutasf: Fixed-point fractional library routines. 44327 (line 917) 44328* __fractutasi: Fixed-point fractional library routines. 44329 (line 913) 44330* __fractutasq: Fixed-point fractional library routines. 44331 (line 886) 44332* __fractutata: Fixed-point fractional library routines. 44333 (line 895) 44334* __fractutati: Fixed-point fractional library routines. 44335 (line 916) 44336* __fractutauda2: Fixed-point fractional library routines. 44337 (line 909) 44338* __fractutaudq: Fixed-point fractional library routines. 44339 (line 903) 44340* __fractutauha2: Fixed-point fractional library routines. 44341 (line 905) 44342* __fractutauhq: Fixed-point fractional library routines. 44343 (line 899) 44344* __fractutauqq: Fixed-point fractional library routines. 44345 (line 897) 44346* __fractutausa2: Fixed-point fractional library routines. 44347 (line 907) 44348* __fractutausq: Fixed-point fractional library routines. 44349 (line 901) 44350* __gedf2: Soft float library routines. 44351 (line 206) 44352* __gesf2: Soft float library routines. 44353 (line 205) 44354* __getf2: Soft float library routines. 44355 (line 207) 44356* __gtdf2: Soft float library routines. 44357 (line 224) 44358* __gtsf2: Soft float library routines. 44359 (line 223) 44360* __gttf2: Soft float library routines. 44361 (line 225) 44362* __ledf2: Soft float library routines. 44363 (line 218) 44364* __lesf2: Soft float library routines. 44365 (line 217) 44366* __letf2: Soft float library routines. 44367 (line 219) 44368* __lshrdi3: Integer library routines. 44369 (line 31) 44370* __lshrsi3: Integer library routines. 44371 (line 30) 44372* __lshrti3: Integer library routines. 44373 (line 32) 44374* __lshruda3: Fixed-point fractional library routines. 44375 (line 390) 44376* __lshrudq3: Fixed-point fractional library routines. 44377 (line 384) 44378* __lshruha3: Fixed-point fractional library routines. 44379 (line 386) 44380* __lshruhq3: Fixed-point fractional library routines. 44381 (line 380) 44382* __lshruqq3: Fixed-point fractional library routines. 44383 (line 378) 44384* __lshrusa3: Fixed-point fractional library routines. 44385 (line 388) 44386* __lshrusq3: Fixed-point fractional library routines. 44387 (line 382) 44388* __lshruta3: Fixed-point fractional library routines. 44389 (line 392) 44390* __ltdf2: Soft float library routines. 44391 (line 212) 44392* __ltsf2: Soft float library routines. 44393 (line 211) 44394* __lttf2: Soft float library routines. 44395 (line 213) 44396* __main: Collect2. (line 15) 44397* __moddi3: Integer library routines. 44398 (line 37) 44399* __modsi3: Integer library routines. 44400 (line 36) 44401* __modti3: Integer library routines. 44402 (line 38) 44403* __morestack_current_segment: Miscellaneous routines. 44404 (line 46) 44405* __morestack_initial_sp: Miscellaneous routines. 44406 (line 47) 44407* __morestack_segments: Miscellaneous routines. 44408 (line 45) 44409* __mulda3: Fixed-point fractional library routines. 44410 (line 171) 44411* __muldc3: Soft float library routines. 44412 (line 241) 44413* __muldf3: Soft float library routines. 44414 (line 40) 44415* __muldi3: Integer library routines. 44416 (line 43) 44417* __muldq3: Fixed-point fractional library routines. 44418 (line 159) 44419* __mulha3: Fixed-point fractional library routines. 44420 (line 169) 44421* __mulhq3: Fixed-point fractional library routines. 44422 (line 156) 44423* __mulqq3: Fixed-point fractional library routines. 44424 (line 155) 44425* __mulsa3: Fixed-point fractional library routines. 44426 (line 170) 44427* __mulsc3: Soft float library routines. 44428 (line 239) 44429* __mulsf3: Soft float library routines. 44430 (line 39) 44431* __mulsi3: Integer library routines. 44432 (line 42) 44433* __mulsq3: Fixed-point fractional library routines. 44434 (line 157) 44435* __multa3: Fixed-point fractional library routines. 44436 (line 173) 44437* __multc3: Soft float library routines. 44438 (line 243) 44439* __multf3: Soft float library routines. 44440 (line 42) 44441* __multi3: Integer library routines. 44442 (line 44) 44443* __muluda3: Fixed-point fractional library routines. 44444 (line 179) 44445* __muludq3: Fixed-point fractional library routines. 44446 (line 167) 44447* __muluha3: Fixed-point fractional library routines. 44448 (line 175) 44449* __muluhq3: Fixed-point fractional library routines. 44450 (line 163) 44451* __muluqq3: Fixed-point fractional library routines. 44452 (line 161) 44453* __mulusa3: Fixed-point fractional library routines. 44454 (line 177) 44455* __mulusq3: Fixed-point fractional library routines. 44456 (line 165) 44457* __muluta3: Fixed-point fractional library routines. 44458 (line 181) 44459* __mulvdi3: Integer library routines. 44460 (line 115) 44461* __mulvsi3: Integer library routines. 44462 (line 114) 44463* __mulxc3: Soft float library routines. 44464 (line 245) 44465* __mulxf3: Soft float library routines. 44466 (line 44) 44467* __nedf2: Soft float library routines. 44468 (line 200) 44469* __negda2: Fixed-point fractional library routines. 44470 (line 299) 44471* __negdf2: Soft float library routines. 44472 (line 56) 44473* __negdi2: Integer library routines. 44474 (line 47) 44475* __negdq2: Fixed-point fractional library routines. 44476 (line 289) 44477* __negha2: Fixed-point fractional library routines. 44478 (line 297) 44479* __neghq2: Fixed-point fractional library routines. 44480 (line 287) 44481* __negqq2: Fixed-point fractional library routines. 44482 (line 286) 44483* __negsa2: Fixed-point fractional library routines. 44484 (line 298) 44485* __negsf2: Soft float library routines. 44486 (line 55) 44487* __negsq2: Fixed-point fractional library routines. 44488 (line 288) 44489* __negta2: Fixed-point fractional library routines. 44490 (line 300) 44491* __negtf2: Soft float library routines. 44492 (line 57) 44493* __negti2: Integer library routines. 44494 (line 48) 44495* __neguda2: Fixed-point fractional library routines. 44496 (line 305) 44497* __negudq2: Fixed-point fractional library routines. 44498 (line 296) 44499* __neguha2: Fixed-point fractional library routines. 44500 (line 302) 44501* __neguhq2: Fixed-point fractional library routines. 44502 (line 292) 44503* __neguqq2: Fixed-point fractional library routines. 44504 (line 291) 44505* __negusa2: Fixed-point fractional library routines. 44506 (line 303) 44507* __negusq2: Fixed-point fractional library routines. 44508 (line 294) 44509* __neguta2: Fixed-point fractional library routines. 44510 (line 307) 44511* __negvdi2: Integer library routines. 44512 (line 119) 44513* __negvsi2: Integer library routines. 44514 (line 118) 44515* __negxf2: Soft float library routines. 44516 (line 58) 44517* __nesf2: Soft float library routines. 44518 (line 199) 44519* __netf2: Soft float library routines. 44520 (line 201) 44521* __paritydi2: Integer library routines. 44522 (line 151) 44523* __paritysi2: Integer library routines. 44524 (line 150) 44525* __parityti2: Integer library routines. 44526 (line 152) 44527* __popcountdi2: Integer library routines. 44528 (line 157) 44529* __popcountsi2: Integer library routines. 44530 (line 156) 44531* __popcountti2: Integer library routines. 44532 (line 158) 44533* __powidf2: Soft float library routines. 44534 (line 233) 44535* __powisf2: Soft float library routines. 44536 (line 232) 44537* __powitf2: Soft float library routines. 44538 (line 234) 44539* __powixf2: Soft float library routines. 44540 (line 235) 44541* __satfractdadq: Fixed-point fractional library routines. 44542 (line 1153) 44543* __satfractdaha2: Fixed-point fractional library routines. 44544 (line 1154) 44545* __satfractdahq: Fixed-point fractional library routines. 44546 (line 1151) 44547* __satfractdaqq: Fixed-point fractional library routines. 44548 (line 1150) 44549* __satfractdasa2: Fixed-point fractional library routines. 44550 (line 1155) 44551* __satfractdasq: Fixed-point fractional library routines. 44552 (line 1152) 44553* __satfractdata2: Fixed-point fractional library routines. 44554 (line 1156) 44555* __satfractdauda: Fixed-point fractional library routines. 44556 (line 1166) 44557* __satfractdaudq: Fixed-point fractional library routines. 44558 (line 1162) 44559* __satfractdauha: Fixed-point fractional library routines. 44560 (line 1164) 44561* __satfractdauhq: Fixed-point fractional library routines. 44562 (line 1159) 44563* __satfractdauqq: Fixed-point fractional library routines. 44564 (line 1158) 44565* __satfractdausa: Fixed-point fractional library routines. 44566 (line 1165) 44567* __satfractdausq: Fixed-point fractional library routines. 44568 (line 1160) 44569* __satfractdauta: Fixed-point fractional library routines. 44570 (line 1168) 44571* __satfractdfda: Fixed-point fractional library routines. 44572 (line 1506) 44573* __satfractdfdq: Fixed-point fractional library routines. 44574 (line 1503) 44575* __satfractdfha: Fixed-point fractional library routines. 44576 (line 1504) 44577* __satfractdfhq: Fixed-point fractional library routines. 44578 (line 1501) 44579* __satfractdfqq: Fixed-point fractional library routines. 44580 (line 1500) 44581* __satfractdfsa: Fixed-point fractional library routines. 44582 (line 1505) 44583* __satfractdfsq: Fixed-point fractional library routines. 44584 (line 1502) 44585* __satfractdfta: Fixed-point fractional library routines. 44586 (line 1507) 44587* __satfractdfuda: Fixed-point fractional library routines. 44588 (line 1515) 44589* __satfractdfudq: Fixed-point fractional library routines. 44590 (line 1512) 44591* __satfractdfuha: Fixed-point fractional library routines. 44592 (line 1513) 44593* __satfractdfuhq: Fixed-point fractional library routines. 44594 (line 1509) 44595* __satfractdfuqq: Fixed-point fractional library routines. 44596 (line 1508) 44597* __satfractdfusa: Fixed-point fractional library routines. 44598 (line 1514) 44599* __satfractdfusq: Fixed-point fractional library routines. 44600 (line 1510) 44601* __satfractdfuta: Fixed-point fractional library routines. 44602 (line 1517) 44603* __satfractdida: Fixed-point fractional library routines. 44604 (line 1456) 44605* __satfractdidq: Fixed-point fractional library routines. 44606 (line 1453) 44607* __satfractdiha: Fixed-point fractional library routines. 44608 (line 1454) 44609* __satfractdihq: Fixed-point fractional library routines. 44610 (line 1451) 44611* __satfractdiqq: Fixed-point fractional library routines. 44612 (line 1450) 44613* __satfractdisa: Fixed-point fractional library routines. 44614 (line 1455) 44615* __satfractdisq: Fixed-point fractional library routines. 44616 (line 1452) 44617* __satfractdita: Fixed-point fractional library routines. 44618 (line 1457) 44619* __satfractdiuda: Fixed-point fractional library routines. 44620 (line 1464) 44621* __satfractdiudq: Fixed-point fractional library routines. 44622 (line 1461) 44623* __satfractdiuha: Fixed-point fractional library routines. 44624 (line 1462) 44625* __satfractdiuhq: Fixed-point fractional library routines. 44626 (line 1459) 44627* __satfractdiuqq: Fixed-point fractional library routines. 44628 (line 1458) 44629* __satfractdiusa: Fixed-point fractional library routines. 44630 (line 1463) 44631* __satfractdiusq: Fixed-point fractional library routines. 44632 (line 1460) 44633* __satfractdiuta: Fixed-point fractional library routines. 44634 (line 1465) 44635* __satfractdqda: Fixed-point fractional library routines. 44636 (line 1098) 44637* __satfractdqha: Fixed-point fractional library routines. 44638 (line 1096) 44639* __satfractdqhq2: Fixed-point fractional library routines. 44640 (line 1094) 44641* __satfractdqqq2: Fixed-point fractional library routines. 44642 (line 1093) 44643* __satfractdqsa: Fixed-point fractional library routines. 44644 (line 1097) 44645* __satfractdqsq2: Fixed-point fractional library routines. 44646 (line 1095) 44647* __satfractdqta: Fixed-point fractional library routines. 44648 (line 1099) 44649* __satfractdquda: Fixed-point fractional library routines. 44650 (line 1111) 44651* __satfractdqudq: Fixed-point fractional library routines. 44652 (line 1106) 44653* __satfractdquha: Fixed-point fractional library routines. 44654 (line 1108) 44655* __satfractdquhq: Fixed-point fractional library routines. 44656 (line 1102) 44657* __satfractdquqq: Fixed-point fractional library routines. 44658 (line 1101) 44659* __satfractdqusa: Fixed-point fractional library routines. 44660 (line 1109) 44661* __satfractdqusq: Fixed-point fractional library routines. 44662 (line 1104) 44663* __satfractdquta: Fixed-point fractional library routines. 44664 (line 1113) 44665* __satfracthada2: Fixed-point fractional library routines. 44666 (line 1119) 44667* __satfracthadq: Fixed-point fractional library routines. 44668 (line 1117) 44669* __satfracthahq: Fixed-point fractional library routines. 44670 (line 1115) 44671* __satfracthaqq: Fixed-point fractional library routines. 44672 (line 1114) 44673* __satfracthasa2: Fixed-point fractional library routines. 44674 (line 1118) 44675* __satfracthasq: Fixed-point fractional library routines. 44676 (line 1116) 44677* __satfracthata2: Fixed-point fractional library routines. 44678 (line 1120) 44679* __satfracthauda: Fixed-point fractional library routines. 44680 (line 1132) 44681* __satfracthaudq: Fixed-point fractional library routines. 44682 (line 1127) 44683* __satfracthauha: Fixed-point fractional library routines. 44684 (line 1129) 44685* __satfracthauhq: Fixed-point fractional library routines. 44686 (line 1123) 44687* __satfracthauqq: Fixed-point fractional library routines. 44688 (line 1122) 44689* __satfracthausa: Fixed-point fractional library routines. 44690 (line 1130) 44691* __satfracthausq: Fixed-point fractional library routines. 44692 (line 1125) 44693* __satfracthauta: Fixed-point fractional library routines. 44694 (line 1134) 44695* __satfracthida: Fixed-point fractional library routines. 44696 (line 1424) 44697* __satfracthidq: Fixed-point fractional library routines. 44698 (line 1421) 44699* __satfracthiha: Fixed-point fractional library routines. 44700 (line 1422) 44701* __satfracthihq: Fixed-point fractional library routines. 44702 (line 1419) 44703* __satfracthiqq: Fixed-point fractional library routines. 44704 (line 1418) 44705* __satfracthisa: Fixed-point fractional library routines. 44706 (line 1423) 44707* __satfracthisq: Fixed-point fractional library routines. 44708 (line 1420) 44709* __satfracthita: Fixed-point fractional library routines. 44710 (line 1425) 44711* __satfracthiuda: Fixed-point fractional library routines. 44712 (line 1432) 44713* __satfracthiudq: Fixed-point fractional library routines. 44714 (line 1429) 44715* __satfracthiuha: Fixed-point fractional library routines. 44716 (line 1430) 44717* __satfracthiuhq: Fixed-point fractional library routines. 44718 (line 1427) 44719* __satfracthiuqq: Fixed-point fractional library routines. 44720 (line 1426) 44721* __satfracthiusa: Fixed-point fractional library routines. 44722 (line 1431) 44723* __satfracthiusq: Fixed-point fractional library routines. 44724 (line 1428) 44725* __satfracthiuta: Fixed-point fractional library routines. 44726 (line 1433) 44727* __satfracthqda: Fixed-point fractional library routines. 44728 (line 1064) 44729* __satfracthqdq2: Fixed-point fractional library routines. 44730 (line 1061) 44731* __satfracthqha: Fixed-point fractional library routines. 44732 (line 1062) 44733* __satfracthqqq2: Fixed-point fractional library routines. 44734 (line 1059) 44735* __satfracthqsa: Fixed-point fractional library routines. 44736 (line 1063) 44737* __satfracthqsq2: Fixed-point fractional library routines. 44738 (line 1060) 44739* __satfracthqta: Fixed-point fractional library routines. 44740 (line 1065) 44741* __satfracthquda: Fixed-point fractional library routines. 44742 (line 1072) 44743* __satfracthqudq: Fixed-point fractional library routines. 44744 (line 1069) 44745* __satfracthquha: Fixed-point fractional library routines. 44746 (line 1070) 44747* __satfracthquhq: Fixed-point fractional library routines. 44748 (line 1067) 44749* __satfracthquqq: Fixed-point fractional library routines. 44750 (line 1066) 44751* __satfracthqusa: Fixed-point fractional library routines. 44752 (line 1071) 44753* __satfracthqusq: Fixed-point fractional library routines. 44754 (line 1068) 44755* __satfracthquta: Fixed-point fractional library routines. 44756 (line 1073) 44757* __satfractqida: Fixed-point fractional library routines. 44758 (line 1402) 44759* __satfractqidq: Fixed-point fractional library routines. 44760 (line 1399) 44761* __satfractqiha: Fixed-point fractional library routines. 44762 (line 1400) 44763* __satfractqihq: Fixed-point fractional library routines. 44764 (line 1397) 44765* __satfractqiqq: Fixed-point fractional library routines. 44766 (line 1396) 44767* __satfractqisa: Fixed-point fractional library routines. 44768 (line 1401) 44769* __satfractqisq: Fixed-point fractional library routines. 44770 (line 1398) 44771* __satfractqita: Fixed-point fractional library routines. 44772 (line 1403) 44773* __satfractqiuda: Fixed-point fractional library routines. 44774 (line 1415) 44775* __satfractqiudq: Fixed-point fractional library routines. 44776 (line 1410) 44777* __satfractqiuha: Fixed-point fractional library routines. 44778 (line 1412) 44779* __satfractqiuhq: Fixed-point fractional library routines. 44780 (line 1406) 44781* __satfractqiuqq: Fixed-point fractional library routines. 44782 (line 1405) 44783* __satfractqiusa: Fixed-point fractional library routines. 44784 (line 1413) 44785* __satfractqiusq: Fixed-point fractional library routines. 44786 (line 1408) 44787* __satfractqiuta: Fixed-point fractional library routines. 44788 (line 1417) 44789* __satfractqqda: Fixed-point fractional library routines. 44790 (line 1043) 44791* __satfractqqdq2: Fixed-point fractional library routines. 44792 (line 1040) 44793* __satfractqqha: Fixed-point fractional library routines. 44794 (line 1041) 44795* __satfractqqhq2: Fixed-point fractional library routines. 44796 (line 1038) 44797* __satfractqqsa: Fixed-point fractional library routines. 44798 (line 1042) 44799* __satfractqqsq2: Fixed-point fractional library routines. 44800 (line 1039) 44801* __satfractqqta: Fixed-point fractional library routines. 44802 (line 1044) 44803* __satfractqquda: Fixed-point fractional library routines. 44804 (line 1056) 44805* __satfractqqudq: Fixed-point fractional library routines. 44806 (line 1051) 44807* __satfractqquha: Fixed-point fractional library routines. 44808 (line 1053) 44809* __satfractqquhq: Fixed-point fractional library routines. 44810 (line 1047) 44811* __satfractqquqq: Fixed-point fractional library routines. 44812 (line 1046) 44813* __satfractqqusa: Fixed-point fractional library routines. 44814 (line 1054) 44815* __satfractqqusq: Fixed-point fractional library routines. 44816 (line 1049) 44817* __satfractqquta: Fixed-point fractional library routines. 44818 (line 1058) 44819* __satfractsada2: Fixed-point fractional library routines. 44820 (line 1140) 44821* __satfractsadq: Fixed-point fractional library routines. 44822 (line 1138) 44823* __satfractsaha2: Fixed-point fractional library routines. 44824 (line 1139) 44825* __satfractsahq: Fixed-point fractional library routines. 44826 (line 1136) 44827* __satfractsaqq: Fixed-point fractional library routines. 44828 (line 1135) 44829* __satfractsasq: Fixed-point fractional library routines. 44830 (line 1137) 44831* __satfractsata2: Fixed-point fractional library routines. 44832 (line 1141) 44833* __satfractsauda: Fixed-point fractional library routines. 44834 (line 1148) 44835* __satfractsaudq: Fixed-point fractional library routines. 44836 (line 1145) 44837* __satfractsauha: Fixed-point fractional library routines. 44838 (line 1146) 44839* __satfractsauhq: Fixed-point fractional library routines. 44840 (line 1143) 44841* __satfractsauqq: Fixed-point fractional library routines. 44842 (line 1142) 44843* __satfractsausa: Fixed-point fractional library routines. 44844 (line 1147) 44845* __satfractsausq: Fixed-point fractional library routines. 44846 (line 1144) 44847* __satfractsauta: Fixed-point fractional library routines. 44848 (line 1149) 44849* __satfractsfda: Fixed-point fractional library routines. 44850 (line 1490) 44851* __satfractsfdq: Fixed-point fractional library routines. 44852 (line 1487) 44853* __satfractsfha: Fixed-point fractional library routines. 44854 (line 1488) 44855* __satfractsfhq: Fixed-point fractional library routines. 44856 (line 1485) 44857* __satfractsfqq: Fixed-point fractional library routines. 44858 (line 1484) 44859* __satfractsfsa: Fixed-point fractional library routines. 44860 (line 1489) 44861* __satfractsfsq: Fixed-point fractional library routines. 44862 (line 1486) 44863* __satfractsfta: Fixed-point fractional library routines. 44864 (line 1491) 44865* __satfractsfuda: Fixed-point fractional library routines. 44866 (line 1498) 44867* __satfractsfudq: Fixed-point fractional library routines. 44868 (line 1495) 44869* __satfractsfuha: Fixed-point fractional library routines. 44870 (line 1496) 44871* __satfractsfuhq: Fixed-point fractional library routines. 44872 (line 1493) 44873* __satfractsfuqq: Fixed-point fractional library routines. 44874 (line 1492) 44875* __satfractsfusa: Fixed-point fractional library routines. 44876 (line 1497) 44877* __satfractsfusq: Fixed-point fractional library routines. 44878 (line 1494) 44879* __satfractsfuta: Fixed-point fractional library routines. 44880 (line 1499) 44881* __satfractsida: Fixed-point fractional library routines. 44882 (line 1440) 44883* __satfractsidq: Fixed-point fractional library routines. 44884 (line 1437) 44885* __satfractsiha: Fixed-point fractional library routines. 44886 (line 1438) 44887* __satfractsihq: Fixed-point fractional library routines. 44888 (line 1435) 44889* __satfractsiqq: Fixed-point fractional library routines. 44890 (line 1434) 44891* __satfractsisa: Fixed-point fractional library routines. 44892 (line 1439) 44893* __satfractsisq: Fixed-point fractional library routines. 44894 (line 1436) 44895* __satfractsita: Fixed-point fractional library routines. 44896 (line 1441) 44897* __satfractsiuda: Fixed-point fractional library routines. 44898 (line 1448) 44899* __satfractsiudq: Fixed-point fractional library routines. 44900 (line 1445) 44901* __satfractsiuha: Fixed-point fractional library routines. 44902 (line 1446) 44903* __satfractsiuhq: Fixed-point fractional library routines. 44904 (line 1443) 44905* __satfractsiuqq: Fixed-point fractional library routines. 44906 (line 1442) 44907* __satfractsiusa: Fixed-point fractional library routines. 44908 (line 1447) 44909* __satfractsiusq: Fixed-point fractional library routines. 44910 (line 1444) 44911* __satfractsiuta: Fixed-point fractional library routines. 44912 (line 1449) 44913* __satfractsqda: Fixed-point fractional library routines. 44914 (line 1079) 44915* __satfractsqdq2: Fixed-point fractional library routines. 44916 (line 1076) 44917* __satfractsqha: Fixed-point fractional library routines. 44918 (line 1077) 44919* __satfractsqhq2: Fixed-point fractional library routines. 44920 (line 1075) 44921* __satfractsqqq2: Fixed-point fractional library routines. 44922 (line 1074) 44923* __satfractsqsa: Fixed-point fractional library routines. 44924 (line 1078) 44925* __satfractsqta: Fixed-point fractional library routines. 44926 (line 1080) 44927* __satfractsquda: Fixed-point fractional library routines. 44928 (line 1090) 44929* __satfractsqudq: Fixed-point fractional library routines. 44930 (line 1086) 44931* __satfractsquha: Fixed-point fractional library routines. 44932 (line 1088) 44933* __satfractsquhq: Fixed-point fractional library routines. 44934 (line 1083) 44935* __satfractsquqq: Fixed-point fractional library routines. 44936 (line 1082) 44937* __satfractsqusa: Fixed-point fractional library routines. 44938 (line 1089) 44939* __satfractsqusq: Fixed-point fractional library routines. 44940 (line 1084) 44941* __satfractsquta: Fixed-point fractional library routines. 44942 (line 1092) 44943* __satfracttada2: Fixed-point fractional library routines. 44944 (line 1175) 44945* __satfracttadq: Fixed-point fractional library routines. 44946 (line 1172) 44947* __satfracttaha2: Fixed-point fractional library routines. 44948 (line 1173) 44949* __satfracttahq: Fixed-point fractional library routines. 44950 (line 1170) 44951* __satfracttaqq: Fixed-point fractional library routines. 44952 (line 1169) 44953* __satfracttasa2: Fixed-point fractional library routines. 44954 (line 1174) 44955* __satfracttasq: Fixed-point fractional library routines. 44956 (line 1171) 44957* __satfracttauda: Fixed-point fractional library routines. 44958 (line 1187) 44959* __satfracttaudq: Fixed-point fractional library routines. 44960 (line 1182) 44961* __satfracttauha: Fixed-point fractional library routines. 44962 (line 1184) 44963* __satfracttauhq: Fixed-point fractional library routines. 44964 (line 1178) 44965* __satfracttauqq: Fixed-point fractional library routines. 44966 (line 1177) 44967* __satfracttausa: Fixed-point fractional library routines. 44968 (line 1185) 44969* __satfracttausq: Fixed-point fractional library routines. 44970 (line 1180) 44971* __satfracttauta: Fixed-point fractional library routines. 44972 (line 1189) 44973* __satfracttida: Fixed-point fractional library routines. 44974 (line 1472) 44975* __satfracttidq: Fixed-point fractional library routines. 44976 (line 1469) 44977* __satfracttiha: Fixed-point fractional library routines. 44978 (line 1470) 44979* __satfracttihq: Fixed-point fractional library routines. 44980 (line 1467) 44981* __satfracttiqq: Fixed-point fractional library routines. 44982 (line 1466) 44983* __satfracttisa: Fixed-point fractional library routines. 44984 (line 1471) 44985* __satfracttisq: Fixed-point fractional library routines. 44986 (line 1468) 44987* __satfracttita: Fixed-point fractional library routines. 44988 (line 1473) 44989* __satfracttiuda: Fixed-point fractional library routines. 44990 (line 1481) 44991* __satfracttiudq: Fixed-point fractional library routines. 44992 (line 1478) 44993* __satfracttiuha: Fixed-point fractional library routines. 44994 (line 1479) 44995* __satfracttiuhq: Fixed-point fractional library routines. 44996 (line 1475) 44997* __satfracttiuqq: Fixed-point fractional library routines. 44998 (line 1474) 44999* __satfracttiusa: Fixed-point fractional library routines. 45000 (line 1480) 45001* __satfracttiusq: Fixed-point fractional library routines. 45002 (line 1476) 45003* __satfracttiuta: Fixed-point fractional library routines. 45004 (line 1483) 45005* __satfractudada: Fixed-point fractional library routines. 45006 (line 1351) 45007* __satfractudadq: Fixed-point fractional library routines. 45008 (line 1347) 45009* __satfractudaha: Fixed-point fractional library routines. 45010 (line 1349) 45011* __satfractudahq: Fixed-point fractional library routines. 45012 (line 1344) 45013* __satfractudaqq: Fixed-point fractional library routines. 45014 (line 1343) 45015* __satfractudasa: Fixed-point fractional library routines. 45016 (line 1350) 45017* __satfractudasq: Fixed-point fractional library routines. 45018 (line 1345) 45019* __satfractudata: Fixed-point fractional library routines. 45020 (line 1353) 45021* __satfractudaudq: Fixed-point fractional library routines. 45022 (line 1361) 45023* __satfractudauha2: Fixed-point fractional library routines. 45024 (line 1363) 45025* __satfractudauhq: Fixed-point fractional library routines. 45026 (line 1357) 45027* __satfractudauqq: Fixed-point fractional library routines. 45028 (line 1355) 45029* __satfractudausa2: Fixed-point fractional library routines. 45030 (line 1365) 45031* __satfractudausq: Fixed-point fractional library routines. 45032 (line 1359) 45033* __satfractudauta2: Fixed-point fractional library routines. 45034 (line 1367) 45035* __satfractudqda: Fixed-point fractional library routines. 45036 (line 1276) 45037* __satfractudqdq: Fixed-point fractional library routines. 45038 (line 1271) 45039* __satfractudqha: Fixed-point fractional library routines. 45040 (line 1273) 45041* __satfractudqhq: Fixed-point fractional library routines. 45042 (line 1267) 45043* __satfractudqqq: Fixed-point fractional library routines. 45044 (line 1266) 45045* __satfractudqsa: Fixed-point fractional library routines. 45046 (line 1274) 45047* __satfractudqsq: Fixed-point fractional library routines. 45048 (line 1269) 45049* __satfractudqta: Fixed-point fractional library routines. 45050 (line 1278) 45051* __satfractudquda: Fixed-point fractional library routines. 45052 (line 1290) 45053* __satfractudquha: Fixed-point fractional library routines. 45054 (line 1286) 45055* __satfractudquhq2: Fixed-point fractional library routines. 45056 (line 1282) 45057* __satfractudquqq2: Fixed-point fractional library routines. 45058 (line 1280) 45059* __satfractudqusa: Fixed-point fractional library routines. 45060 (line 1288) 45061* __satfractudqusq2: Fixed-point fractional library routines. 45062 (line 1284) 45063* __satfractudquta: Fixed-point fractional library routines. 45064 (line 1292) 45065* __satfractuhada: Fixed-point fractional library routines. 45066 (line 1304) 45067* __satfractuhadq: Fixed-point fractional library routines. 45068 (line 1299) 45069* __satfractuhaha: Fixed-point fractional library routines. 45070 (line 1301) 45071* __satfractuhahq: Fixed-point fractional library routines. 45072 (line 1295) 45073* __satfractuhaqq: Fixed-point fractional library routines. 45074 (line 1294) 45075* __satfractuhasa: Fixed-point fractional library routines. 45076 (line 1302) 45077* __satfractuhasq: Fixed-point fractional library routines. 45078 (line 1297) 45079* __satfractuhata: Fixed-point fractional library routines. 45080 (line 1306) 45081* __satfractuhauda2: Fixed-point fractional library routines. 45082 (line 1318) 45083* __satfractuhaudq: Fixed-point fractional library routines. 45084 (line 1314) 45085* __satfractuhauhq: Fixed-point fractional library routines. 45086 (line 1310) 45087* __satfractuhauqq: Fixed-point fractional library routines. 45088 (line 1308) 45089* __satfractuhausa2: Fixed-point fractional library routines. 45090 (line 1316) 45091* __satfractuhausq: Fixed-point fractional library routines. 45092 (line 1312) 45093* __satfractuhauta2: Fixed-point fractional library routines. 45094 (line 1320) 45095* __satfractuhqda: Fixed-point fractional library routines. 45096 (line 1224) 45097* __satfractuhqdq: Fixed-point fractional library routines. 45098 (line 1221) 45099* __satfractuhqha: Fixed-point fractional library routines. 45100 (line 1222) 45101* __satfractuhqhq: Fixed-point fractional library routines. 45102 (line 1219) 45103* __satfractuhqqq: Fixed-point fractional library routines. 45104 (line 1218) 45105* __satfractuhqsa: Fixed-point fractional library routines. 45106 (line 1223) 45107* __satfractuhqsq: Fixed-point fractional library routines. 45108 (line 1220) 45109* __satfractuhqta: Fixed-point fractional library routines. 45110 (line 1225) 45111* __satfractuhquda: Fixed-point fractional library routines. 45112 (line 1236) 45113* __satfractuhqudq2: Fixed-point fractional library routines. 45114 (line 1231) 45115* __satfractuhquha: Fixed-point fractional library routines. 45116 (line 1233) 45117* __satfractuhquqq2: Fixed-point fractional library routines. 45118 (line 1227) 45119* __satfractuhqusa: Fixed-point fractional library routines. 45120 (line 1234) 45121* __satfractuhqusq2: Fixed-point fractional library routines. 45122 (line 1229) 45123* __satfractuhquta: Fixed-point fractional library routines. 45124 (line 1238) 45125* __satfractunsdida: Fixed-point fractional library routines. 45126 (line 1834) 45127* __satfractunsdidq: Fixed-point fractional library routines. 45128 (line 1831) 45129* __satfractunsdiha: Fixed-point fractional library routines. 45130 (line 1832) 45131* __satfractunsdihq: Fixed-point fractional library routines. 45132 (line 1828) 45133* __satfractunsdiqq: Fixed-point fractional library routines. 45134 (line 1827) 45135* __satfractunsdisa: Fixed-point fractional library routines. 45136 (line 1833) 45137* __satfractunsdisq: Fixed-point fractional library routines. 45138 (line 1829) 45139* __satfractunsdita: Fixed-point fractional library routines. 45140 (line 1836) 45141* __satfractunsdiuda: Fixed-point fractional library routines. 45142 (line 1850) 45143* __satfractunsdiudq: Fixed-point fractional library routines. 45144 (line 1844) 45145* __satfractunsdiuha: Fixed-point fractional library routines. 45146 (line 1846) 45147* __satfractunsdiuhq: Fixed-point fractional library routines. 45148 (line 1840) 45149* __satfractunsdiuqq: Fixed-point fractional library routines. 45150 (line 1838) 45151* __satfractunsdiusa: Fixed-point fractional library routines. 45152 (line 1848) 45153* __satfractunsdiusq: Fixed-point fractional library routines. 45154 (line 1842) 45155* __satfractunsdiuta: Fixed-point fractional library routines. 45156 (line 1852) 45157* __satfractunshida: Fixed-point fractional library routines. 45158 (line 1786) 45159* __satfractunshidq: Fixed-point fractional library routines. 45160 (line 1783) 45161* __satfractunshiha: Fixed-point fractional library routines. 45162 (line 1784) 45163* __satfractunshihq: Fixed-point fractional library routines. 45164 (line 1780) 45165* __satfractunshiqq: Fixed-point fractional library routines. 45166 (line 1779) 45167* __satfractunshisa: Fixed-point fractional library routines. 45168 (line 1785) 45169* __satfractunshisq: Fixed-point fractional library routines. 45170 (line 1781) 45171* __satfractunshita: Fixed-point fractional library routines. 45172 (line 1788) 45173* __satfractunshiuda: Fixed-point fractional library routines. 45174 (line 1802) 45175* __satfractunshiudq: Fixed-point fractional library routines. 45176 (line 1796) 45177* __satfractunshiuha: Fixed-point fractional library routines. 45178 (line 1798) 45179* __satfractunshiuhq: Fixed-point fractional library routines. 45180 (line 1792) 45181* __satfractunshiuqq: Fixed-point fractional library routines. 45182 (line 1790) 45183* __satfractunshiusa: Fixed-point fractional library routines. 45184 (line 1800) 45185* __satfractunshiusq: Fixed-point fractional library routines. 45186 (line 1794) 45187* __satfractunshiuta: Fixed-point fractional library routines. 45188 (line 1804) 45189* __satfractunsqida: Fixed-point fractional library routines. 45190 (line 1760) 45191* __satfractunsqidq: Fixed-point fractional library routines. 45192 (line 1757) 45193* __satfractunsqiha: Fixed-point fractional library routines. 45194 (line 1758) 45195* __satfractunsqihq: Fixed-point fractional library routines. 45196 (line 1754) 45197* __satfractunsqiqq: Fixed-point fractional library routines. 45198 (line 1753) 45199* __satfractunsqisa: Fixed-point fractional library routines. 45200 (line 1759) 45201* __satfractunsqisq: Fixed-point fractional library routines. 45202 (line 1755) 45203* __satfractunsqita: Fixed-point fractional library routines. 45204 (line 1762) 45205* __satfractunsqiuda: Fixed-point fractional library routines. 45206 (line 1776) 45207* __satfractunsqiudq: Fixed-point fractional library routines. 45208 (line 1770) 45209* __satfractunsqiuha: Fixed-point fractional library routines. 45210 (line 1772) 45211* __satfractunsqiuhq: Fixed-point fractional library routines. 45212 (line 1766) 45213* __satfractunsqiuqq: Fixed-point fractional library routines. 45214 (line 1764) 45215* __satfractunsqiusa: Fixed-point fractional library routines. 45216 (line 1774) 45217* __satfractunsqiusq: Fixed-point fractional library routines. 45218 (line 1768) 45219* __satfractunsqiuta: Fixed-point fractional library routines. 45220 (line 1778) 45221* __satfractunssida: Fixed-point fractional library routines. 45222 (line 1811) 45223* __satfractunssidq: Fixed-point fractional library routines. 45224 (line 1808) 45225* __satfractunssiha: Fixed-point fractional library routines. 45226 (line 1809) 45227* __satfractunssihq: Fixed-point fractional library routines. 45228 (line 1806) 45229* __satfractunssiqq: Fixed-point fractional library routines. 45230 (line 1805) 45231* __satfractunssisa: Fixed-point fractional library routines. 45232 (line 1810) 45233* __satfractunssisq: Fixed-point fractional library routines. 45234 (line 1807) 45235* __satfractunssita: Fixed-point fractional library routines. 45236 (line 1812) 45237* __satfractunssiuda: Fixed-point fractional library routines. 45238 (line 1824) 45239* __satfractunssiudq: Fixed-point fractional library routines. 45240 (line 1819) 45241* __satfractunssiuha: Fixed-point fractional library routines. 45242 (line 1821) 45243* __satfractunssiuhq: Fixed-point fractional library routines. 45244 (line 1815) 45245* __satfractunssiuqq: Fixed-point fractional library routines. 45246 (line 1814) 45247* __satfractunssiusa: Fixed-point fractional library routines. 45248 (line 1822) 45249* __satfractunssiusq: Fixed-point fractional library routines. 45250 (line 1817) 45251* __satfractunssiuta: Fixed-point fractional library routines. 45252 (line 1826) 45253* __satfractunstida: Fixed-point fractional library routines. 45254 (line 1864) 45255* __satfractunstidq: Fixed-point fractional library routines. 45256 (line 1859) 45257* __satfractunstiha: Fixed-point fractional library routines. 45258 (line 1861) 45259* __satfractunstihq: Fixed-point fractional library routines. 45260 (line 1855) 45261* __satfractunstiqq: Fixed-point fractional library routines. 45262 (line 1854) 45263* __satfractunstisa: Fixed-point fractional library routines. 45264 (line 1862) 45265* __satfractunstisq: Fixed-point fractional library routines. 45266 (line 1857) 45267* __satfractunstita: Fixed-point fractional library routines. 45268 (line 1866) 45269* __satfractunstiuda: Fixed-point fractional library routines. 45270 (line 1880) 45271* __satfractunstiudq: Fixed-point fractional library routines. 45272 (line 1874) 45273* __satfractunstiuha: Fixed-point fractional library routines. 45274 (line 1876) 45275* __satfractunstiuhq: Fixed-point fractional library routines. 45276 (line 1870) 45277* __satfractunstiuqq: Fixed-point fractional library routines. 45278 (line 1868) 45279* __satfractunstiusa: Fixed-point fractional library routines. 45280 (line 1878) 45281* __satfractunstiusq: Fixed-point fractional library routines. 45282 (line 1872) 45283* __satfractunstiuta: Fixed-point fractional library routines. 45284 (line 1882) 45285* __satfractuqqda: Fixed-point fractional library routines. 45286 (line 1201) 45287* __satfractuqqdq: Fixed-point fractional library routines. 45288 (line 1196) 45289* __satfractuqqha: Fixed-point fractional library routines. 45290 (line 1198) 45291* __satfractuqqhq: Fixed-point fractional library routines. 45292 (line 1192) 45293* __satfractuqqqq: Fixed-point fractional library routines. 45294 (line 1191) 45295* __satfractuqqsa: Fixed-point fractional library routines. 45296 (line 1199) 45297* __satfractuqqsq: Fixed-point fractional library routines. 45298 (line 1194) 45299* __satfractuqqta: Fixed-point fractional library routines. 45300 (line 1203) 45301* __satfractuqquda: Fixed-point fractional library routines. 45302 (line 1215) 45303* __satfractuqqudq2: Fixed-point fractional library routines. 45304 (line 1209) 45305* __satfractuqquha: Fixed-point fractional library routines. 45306 (line 1211) 45307* __satfractuqquhq2: Fixed-point fractional library routines. 45308 (line 1205) 45309* __satfractuqqusa: Fixed-point fractional library routines. 45310 (line 1213) 45311* __satfractuqqusq2: Fixed-point fractional library routines. 45312 (line 1207) 45313* __satfractuqquta: Fixed-point fractional library routines. 45314 (line 1217) 45315* __satfractusada: Fixed-point fractional library routines. 45316 (line 1327) 45317* __satfractusadq: Fixed-point fractional library routines. 45318 (line 1324) 45319* __satfractusaha: Fixed-point fractional library routines. 45320 (line 1325) 45321* __satfractusahq: Fixed-point fractional library routines. 45322 (line 1322) 45323* __satfractusaqq: Fixed-point fractional library routines. 45324 (line 1321) 45325* __satfractusasa: Fixed-point fractional library routines. 45326 (line 1326) 45327* __satfractusasq: Fixed-point fractional library routines. 45328 (line 1323) 45329* __satfractusata: Fixed-point fractional library routines. 45330 (line 1328) 45331* __satfractusauda2: Fixed-point fractional library routines. 45332 (line 1339) 45333* __satfractusaudq: Fixed-point fractional library routines. 45334 (line 1335) 45335* __satfractusauha2: Fixed-point fractional library routines. 45336 (line 1337) 45337* __satfractusauhq: Fixed-point fractional library routines. 45338 (line 1331) 45339* __satfractusauqq: Fixed-point fractional library routines. 45340 (line 1330) 45341* __satfractusausq: Fixed-point fractional library routines. 45342 (line 1333) 45343* __satfractusauta2: Fixed-point fractional library routines. 45344 (line 1341) 45345* __satfractusqda: Fixed-point fractional library routines. 45346 (line 1248) 45347* __satfractusqdq: Fixed-point fractional library routines. 45348 (line 1244) 45349* __satfractusqha: Fixed-point fractional library routines. 45350 (line 1246) 45351* __satfractusqhq: Fixed-point fractional library routines. 45352 (line 1241) 45353* __satfractusqqq: Fixed-point fractional library routines. 45354 (line 1240) 45355* __satfractusqsa: Fixed-point fractional library routines. 45356 (line 1247) 45357* __satfractusqsq: Fixed-point fractional library routines. 45358 (line 1242) 45359* __satfractusqta: Fixed-point fractional library routines. 45360 (line 1250) 45361* __satfractusquda: Fixed-point fractional library routines. 45362 (line 1262) 45363* __satfractusqudq2: Fixed-point fractional library routines. 45364 (line 1256) 45365* __satfractusquha: Fixed-point fractional library routines. 45366 (line 1258) 45367* __satfractusquhq2: Fixed-point fractional library routines. 45368 (line 1254) 45369* __satfractusquqq2: Fixed-point fractional library routines. 45370 (line 1252) 45371* __satfractusqusa: Fixed-point fractional library routines. 45372 (line 1260) 45373* __satfractusquta: Fixed-point fractional library routines. 45374 (line 1264) 45375* __satfractutada: Fixed-point fractional library routines. 45376 (line 1379) 45377* __satfractutadq: Fixed-point fractional library routines. 45378 (line 1374) 45379* __satfractutaha: Fixed-point fractional library routines. 45380 (line 1376) 45381* __satfractutahq: Fixed-point fractional library routines. 45382 (line 1370) 45383* __satfractutaqq: Fixed-point fractional library routines. 45384 (line 1369) 45385* __satfractutasa: Fixed-point fractional library routines. 45386 (line 1377) 45387* __satfractutasq: Fixed-point fractional library routines. 45388 (line 1372) 45389* __satfractutata: Fixed-point fractional library routines. 45390 (line 1381) 45391* __satfractutauda2: Fixed-point fractional library routines. 45392 (line 1395) 45393* __satfractutaudq: Fixed-point fractional library routines. 45394 (line 1389) 45395* __satfractutauha2: Fixed-point fractional library routines. 45396 (line 1391) 45397* __satfractutauhq: Fixed-point fractional library routines. 45398 (line 1385) 45399* __satfractutauqq: Fixed-point fractional library routines. 45400 (line 1383) 45401* __satfractutausa2: Fixed-point fractional library routines. 45402 (line 1393) 45403* __satfractutausq: Fixed-point fractional library routines. 45404 (line 1387) 45405* __splitstack_find: Miscellaneous routines. 45406 (line 18) 45407* __ssaddda3: Fixed-point fractional library routines. 45408 (line 67) 45409* __ssadddq3: Fixed-point fractional library routines. 45410 (line 63) 45411* __ssaddha3: Fixed-point fractional library routines. 45412 (line 65) 45413* __ssaddhq3: Fixed-point fractional library routines. 45414 (line 60) 45415* __ssaddqq3: Fixed-point fractional library routines. 45416 (line 59) 45417* __ssaddsa3: Fixed-point fractional library routines. 45418 (line 66) 45419* __ssaddsq3: Fixed-point fractional library routines. 45420 (line 61) 45421* __ssaddta3: Fixed-point fractional library routines. 45422 (line 69) 45423* __ssashlda3: Fixed-point fractional library routines. 45424 (line 402) 45425* __ssashldq3: Fixed-point fractional library routines. 45426 (line 399) 45427* __ssashlha3: Fixed-point fractional library routines. 45428 (line 400) 45429* __ssashlhq3: Fixed-point fractional library routines. 45430 (line 396) 45431* __ssashlsa3: Fixed-point fractional library routines. 45432 (line 401) 45433* __ssashlsq3: Fixed-point fractional library routines. 45434 (line 397) 45435* __ssashlta3: Fixed-point fractional library routines. 45436 (line 404) 45437* __ssdivda3: Fixed-point fractional library routines. 45438 (line 261) 45439* __ssdivdq3: Fixed-point fractional library routines. 45440 (line 257) 45441* __ssdivha3: Fixed-point fractional library routines. 45442 (line 259) 45443* __ssdivhq3: Fixed-point fractional library routines. 45444 (line 254) 45445* __ssdivqq3: Fixed-point fractional library routines. 45446 (line 253) 45447* __ssdivsa3: Fixed-point fractional library routines. 45448 (line 260) 45449* __ssdivsq3: Fixed-point fractional library routines. 45450 (line 255) 45451* __ssdivta3: Fixed-point fractional library routines. 45452 (line 263) 45453* __ssmulda3: Fixed-point fractional library routines. 45454 (line 193) 45455* __ssmuldq3: Fixed-point fractional library routines. 45456 (line 189) 45457* __ssmulha3: Fixed-point fractional library routines. 45458 (line 191) 45459* __ssmulhq3: Fixed-point fractional library routines. 45460 (line 186) 45461* __ssmulqq3: Fixed-point fractional library routines. 45462 (line 185) 45463* __ssmulsa3: Fixed-point fractional library routines. 45464 (line 192) 45465* __ssmulsq3: Fixed-point fractional library routines. 45466 (line 187) 45467* __ssmulta3: Fixed-point fractional library routines. 45468 (line 195) 45469* __ssnegda2: Fixed-point fractional library routines. 45470 (line 316) 45471* __ssnegdq2: Fixed-point fractional library routines. 45472 (line 313) 45473* __ssnegha2: Fixed-point fractional library routines. 45474 (line 314) 45475* __ssneghq2: Fixed-point fractional library routines. 45476 (line 311) 45477* __ssnegqq2: Fixed-point fractional library routines. 45478 (line 310) 45479* __ssnegsa2: Fixed-point fractional library routines. 45480 (line 315) 45481* __ssnegsq2: Fixed-point fractional library routines. 45482 (line 312) 45483* __ssnegta2: Fixed-point fractional library routines. 45484 (line 317) 45485* __sssubda3: Fixed-point fractional library routines. 45486 (line 129) 45487* __sssubdq3: Fixed-point fractional library routines. 45488 (line 125) 45489* __sssubha3: Fixed-point fractional library routines. 45490 (line 127) 45491* __sssubhq3: Fixed-point fractional library routines. 45492 (line 122) 45493* __sssubqq3: Fixed-point fractional library routines. 45494 (line 121) 45495* __sssubsa3: Fixed-point fractional library routines. 45496 (line 128) 45497* __sssubsq3: Fixed-point fractional library routines. 45498 (line 123) 45499* __sssubta3: Fixed-point fractional library routines. 45500 (line 131) 45501* __subda3: Fixed-point fractional library routines. 45502 (line 107) 45503* __subdf3: Soft float library routines. 45504 (line 31) 45505* __subdq3: Fixed-point fractional library routines. 45506 (line 95) 45507* __subha3: Fixed-point fractional library routines. 45508 (line 105) 45509* __subhq3: Fixed-point fractional library routines. 45510 (line 92) 45511* __subqq3: Fixed-point fractional library routines. 45512 (line 91) 45513* __subsa3: Fixed-point fractional library routines. 45514 (line 106) 45515* __subsf3: Soft float library routines. 45516 (line 30) 45517* __subsq3: Fixed-point fractional library routines. 45518 (line 93) 45519* __subta3: Fixed-point fractional library routines. 45520 (line 109) 45521* __subtf3: Soft float library routines. 45522 (line 33) 45523* __subuda3: Fixed-point fractional library routines. 45524 (line 115) 45525* __subudq3: Fixed-point fractional library routines. 45526 (line 103) 45527* __subuha3: Fixed-point fractional library routines. 45528 (line 111) 45529* __subuhq3: Fixed-point fractional library routines. 45530 (line 99) 45531* __subuqq3: Fixed-point fractional library routines. 45532 (line 97) 45533* __subusa3: Fixed-point fractional library routines. 45534 (line 113) 45535* __subusq3: Fixed-point fractional library routines. 45536 (line 101) 45537* __subuta3: Fixed-point fractional library routines. 45538 (line 117) 45539* __subvdi3: Integer library routines. 45540 (line 123) 45541* __subvsi3: Integer library routines. 45542 (line 122) 45543* __subxf3: Soft float library routines. 45544 (line 35) 45545* __truncdfsf2: Soft float library routines. 45546 (line 76) 45547* __trunctfdf2: Soft float library routines. 45548 (line 73) 45549* __trunctfsf2: Soft float library routines. 45550 (line 75) 45551* __truncxfdf2: Soft float library routines. 45552 (line 72) 45553* __truncxfsf2: Soft float library routines. 45554 (line 74) 45555* __ucmpdi2: Integer library routines. 45556 (line 93) 45557* __ucmpti2: Integer library routines. 45558 (line 95) 45559* __udivdi3: Integer library routines. 45560 (line 54) 45561* __udivmoddi4: Integer library routines. 45562 (line 61) 45563* __udivmodti4: Integer library routines. 45564 (line 63) 45565* __udivsi3: Integer library routines. 45566 (line 52) 45567* __udivti3: Integer library routines. 45568 (line 56) 45569* __udivuda3: Fixed-point fractional library routines. 45570 (line 246) 45571* __udivudq3: Fixed-point fractional library routines. 45572 (line 240) 45573* __udivuha3: Fixed-point fractional library routines. 45574 (line 242) 45575* __udivuhq3: Fixed-point fractional library routines. 45576 (line 236) 45577* __udivuqq3: Fixed-point fractional library routines. 45578 (line 234) 45579* __udivusa3: Fixed-point fractional library routines. 45580 (line 244) 45581* __udivusq3: Fixed-point fractional library routines. 45582 (line 238) 45583* __udivuta3: Fixed-point fractional library routines. 45584 (line 248) 45585* __umoddi3: Integer library routines. 45586 (line 71) 45587* __umodsi3: Integer library routines. 45588 (line 69) 45589* __umodti3: Integer library routines. 45590 (line 73) 45591* __unorddf2: Soft float library routines. 45592 (line 173) 45593* __unordsf2: Soft float library routines. 45594 (line 172) 45595* __unordtf2: Soft float library routines. 45596 (line 174) 45597* __usadduda3: Fixed-point fractional library routines. 45598 (line 85) 45599* __usaddudq3: Fixed-point fractional library routines. 45600 (line 79) 45601* __usadduha3: Fixed-point fractional library routines. 45602 (line 81) 45603* __usadduhq3: Fixed-point fractional library routines. 45604 (line 75) 45605* __usadduqq3: Fixed-point fractional library routines. 45606 (line 73) 45607* __usaddusa3: Fixed-point fractional library routines. 45608 (line 83) 45609* __usaddusq3: Fixed-point fractional library routines. 45610 (line 77) 45611* __usadduta3: Fixed-point fractional library routines. 45612 (line 87) 45613* __usashluda3: Fixed-point fractional library routines. 45614 (line 421) 45615* __usashludq3: Fixed-point fractional library routines. 45616 (line 415) 45617* __usashluha3: Fixed-point fractional library routines. 45618 (line 417) 45619* __usashluhq3: Fixed-point fractional library routines. 45620 (line 411) 45621* __usashluqq3: Fixed-point fractional library routines. 45622 (line 409) 45623* __usashlusa3: Fixed-point fractional library routines. 45624 (line 419) 45625* __usashlusq3: Fixed-point fractional library routines. 45626 (line 413) 45627* __usashluta3: Fixed-point fractional library routines. 45628 (line 423) 45629* __usdivuda3: Fixed-point fractional library routines. 45630 (line 280) 45631* __usdivudq3: Fixed-point fractional library routines. 45632 (line 274) 45633* __usdivuha3: Fixed-point fractional library routines. 45634 (line 276) 45635* __usdivuhq3: Fixed-point fractional library routines. 45636 (line 270) 45637* __usdivuqq3: Fixed-point fractional library routines. 45638 (line 268) 45639* __usdivusa3: Fixed-point fractional library routines. 45640 (line 278) 45641* __usdivusq3: Fixed-point fractional library routines. 45642 (line 272) 45643* __usdivuta3: Fixed-point fractional library routines. 45644 (line 282) 45645* __usmuluda3: Fixed-point fractional library routines. 45646 (line 212) 45647* __usmuludq3: Fixed-point fractional library routines. 45648 (line 206) 45649* __usmuluha3: Fixed-point fractional library routines. 45650 (line 208) 45651* __usmuluhq3: Fixed-point fractional library routines. 45652 (line 202) 45653* __usmuluqq3: Fixed-point fractional library routines. 45654 (line 200) 45655* __usmulusa3: Fixed-point fractional library routines. 45656 (line 210) 45657* __usmulusq3: Fixed-point fractional library routines. 45658 (line 204) 45659* __usmuluta3: Fixed-point fractional library routines. 45660 (line 214) 45661* __usneguda2: Fixed-point fractional library routines. 45662 (line 331) 45663* __usnegudq2: Fixed-point fractional library routines. 45664 (line 326) 45665* __usneguha2: Fixed-point fractional library routines. 45666 (line 328) 45667* __usneguhq2: Fixed-point fractional library routines. 45668 (line 322) 45669* __usneguqq2: Fixed-point fractional library routines. 45670 (line 321) 45671* __usnegusa2: Fixed-point fractional library routines. 45672 (line 329) 45673* __usnegusq2: Fixed-point fractional library routines. 45674 (line 324) 45675* __usneguta2: Fixed-point fractional library routines. 45676 (line 333) 45677* __ussubuda3: Fixed-point fractional library routines. 45678 (line 148) 45679* __ussubudq3: Fixed-point fractional library routines. 45680 (line 142) 45681* __ussubuha3: Fixed-point fractional library routines. 45682 (line 144) 45683* __ussubuhq3: Fixed-point fractional library routines. 45684 (line 138) 45685* __ussubuqq3: Fixed-point fractional library routines. 45686 (line 136) 45687* __ussubusa3: Fixed-point fractional library routines. 45688 (line 146) 45689* __ussubusq3: Fixed-point fractional library routines. 45690 (line 140) 45691* __ussubuta3: Fixed-point fractional library routines. 45692 (line 150) 45693* abort: Portability. (line 21) 45694* abs: Arithmetic. (line 200) 45695* abs and attributes: Expressions. (line 85) 45696* ABS_EXPR: Unary and Binary Expressions. 45697 (line 6) 45698* absence_set: Processor pipeline description. 45699 (line 224) 45700* absM2 instruction pattern: Standard Names. (line 535) 45701* absolute value: Arithmetic. (line 200) 45702* access to operands: Accessors. (line 6) 45703* access to special operands: Special Accessors. (line 6) 45704* accessors: Accessors. (line 6) 45705* ACCUM_TYPE_SIZE: Type Layout. (line 88) 45706* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 49) 45707* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135) 45708* ADA_LONG_TYPE_SIZE: Type Layout. (line 26) 45709* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 45710 (line 6) 45711* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15) 45712* addM3 instruction pattern: Standard Names. (line 263) 45713* addMODEcc instruction pattern: Standard Names. (line 1050) 45714* addr_diff_vec: Side Effects. (line 308) 45715* addr_diff_vec, length of: Insn Lengths. (line 26) 45716* ADDR_EXPR: Storage References. (line 6) 45717* addr_vec: Side Effects. (line 303) 45718* addr_vec, length of: Insn Lengths. (line 26) 45719* address constraints: Simple Constraints. (line 164) 45720* address_operand <1>: Simple Constraints. (line 168) 45721* address_operand: Machine-Independent Predicates. 45722 (line 63) 45723* addressing modes: Addressing Modes. (line 6) 45724* ADJUST_FIELD_ALIGN: Storage Layout. (line 197) 45725* ADJUST_INSN_LENGTH: Insn Lengths. (line 35) 45726* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 23) 45727* aggregates as return values: Aggregate Return. (line 6) 45728* alias: Alias analysis. (line 6) 45729* ALL_REGS: Register Classes. (line 17) 45730* allocate_stack instruction pattern: Standard Names. (line 1375) 45731* alternate entry points: Insns. (line 146) 45732* anchored addresses: Anchored Addresses. (line 6) 45733* and: Arithmetic. (line 158) 45734* and and attributes: Expressions. (line 50) 45735* and, canonicalization of: Insn Canonicalizations. 45736 (line 52) 45737* andM3 instruction pattern: Standard Names. (line 269) 45738* annotations: Annotations. (line 6) 45739* APPLY_RESULT_SIZE: Scalar Return. (line 112) 45740* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194) 45741* ARG_POINTER_REGNUM: Frame Registers. (line 41) 45742* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 45743* arg_pointer_rtx: Frame Registers. (line 104) 45744* ARGS_GROW_DOWNWARD: Frame Layout. (line 35) 45745* argument passing: Interface. (line 36) 45746* arguments in registers: Register Arguments. (line 6) 45747* arguments on stack: Stack Arguments. (line 6) 45748* arithmetic library: Soft float library routines. 45749 (line 6) 45750* arithmetic shift: Arithmetic. (line 173) 45751* arithmetic shift with signed saturation: Arithmetic. (line 173) 45752* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 45753* arithmetic, in RTL: Arithmetic. (line 6) 45754* ARITHMETIC_TYPE_P: Types for C++. (line 61) 45755* array: Types. (line 6) 45756* ARRAY_RANGE_REF: Storage References. (line 6) 45757* ARRAY_REF: Storage References. (line 6) 45758* ARRAY_TYPE: Types. (line 6) 45759* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 89) 45760* ashift: Arithmetic. (line 173) 45761* ashift and attributes: Expressions. (line 85) 45762* ashiftrt: Arithmetic. (line 190) 45763* ashiftrt and attributes: Expressions. (line 85) 45764* ashlM3 instruction pattern: Standard Names. (line 510) 45765* ashrM3 instruction pattern: Standard Names. (line 520) 45766* ASM_APP_OFF: File Framework. (line 78) 45767* ASM_APP_ON: File Framework. (line 71) 45768* ASM_COMMENT_START: File Framework. (line 66) 45769* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 111) 45770* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 126) 45771* ASM_DECLARE_OBJECT_NAME: Label Output. (line 139) 45772* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 168) 45773* ASM_FINAL_SPEC: Driver. (line 82) 45774* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 176) 45775* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 395) 45776* asm_fprintf: Instruction Output. (line 151) 45777* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 162) 45778* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 379) 45779* asm_input: Side Effects. (line 290) 45780* asm_input and /v: Flags. (line 76) 45781* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82) 45782* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 79) 45783* asm_noperands: Insns. (line 314) 45784* asm_operands and /v: Flags. (line 76) 45785* asm_operands, RTL sharing: Sharing. (line 45) 45786* asm_operands, usage: Assembler. (line 6) 45787* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9) 45788* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26) 45789* ASM_OUTPUT_ALIGN: Alignment Output. (line 86) 45790* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 91) 45791* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 46) 45792* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 30) 45793* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 38) 45794* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 91) 45795* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 83) 45796* ASM_OUTPUT_ASCII: Data Output. (line 51) 45797* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51) 45798* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38) 45799* ASM_OUTPUT_COMMON: Uninitialized Data. (line 10) 45800* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 367) 45801* ASM_OUTPUT_DEF: Label Output. (line 416) 45802* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 424) 45803* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 74) 45804* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 83) 45805* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 89) 45806* ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 94) 45807* ASM_OUTPUT_DWARF_VMS_DELTA: SDB and DWARF. (line 78) 45808* ASM_OUTPUT_EXTERNAL: Label Output. (line 296) 45809* ASM_OUTPUT_FDESC: Data Output. (line 60) 45810* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 17) 45811* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 29) 45812* ASM_OUTPUT_LABEL: Label Output. (line 9) 45813* ASM_OUTPUT_LABEL_REF: Label Output. (line 340) 45814* ASM_OUTPUT_LABELREF: Label Output. (line 318) 45815* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 70) 45816* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 95) 45817* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 53) 45818* ASM_OUTPUT_OPCODE: Instruction Output. (line 36) 45819* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 110) 45820* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 73) 45821* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 45822* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 45823* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 47) 45824* ASM_OUTPUT_SKIP: Alignment Output. (line 73) 45825* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 85) 45826* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 85) 45827* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 333) 45828* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 101) 45829* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 442) 45830* ASM_OUTPUT_WEAKREF: Label Output. (line 228) 45831* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67) 45832* ASM_SPEC: Driver. (line 74) 45833* ASM_STABD_OP: DBX Options. (line 36) 45834* ASM_STABN_OP: DBX Options. (line 43) 45835* ASM_STABS_OP: DBX Options. (line 29) 45836* ASM_WEAKEN_DECL: Label Output. (line 220) 45837* ASM_WEAKEN_LABEL: Label Output. (line 207) 45838* assemble_name: Label Output. (line 8) 45839* assemble_name_raw: Label Output. (line 28) 45840* assembler format: File Framework. (line 6) 45841* assembler instructions in RTL: Assembler. (line 6) 45842* ASSEMBLER_DIALECT: Instruction Output. (line 174) 45843* assigning attribute values to insns: Tagging Insns. (line 6) 45844* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 164) 45845* asterisk in template: Output Statement. (line 29) 45846* atan2M3 instruction pattern: Standard Names. (line 618) 45847* atomic: GTY Options. (line 254) 45848* atomic_add_fetchMODE instruction pattern: Standard Names. (line 1808) 45849* atomic_addMODE instruction pattern: Standard Names. (line 1779) 45850* atomic_and_fetchMODE instruction pattern: Standard Names. (line 1808) 45851* atomic_andMODE instruction pattern: Standard Names. (line 1779) 45852* atomic_compare_and_swapMODE instruction pattern: Standard Names. 45853 (line 1715) 45854* atomic_exchangeMODE instruction pattern: Standard Names. (line 1767) 45855* atomic_fetch_addMODE instruction pattern: Standard Names. (line 1793) 45856* atomic_fetch_andMODE instruction pattern: Standard Names. (line 1793) 45857* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 1793) 45858* atomic_fetch_orMODE instruction pattern: Standard Names. (line 1793) 45859* atomic_fetch_subMODE instruction pattern: Standard Names. (line 1793) 45860* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 1793) 45861* atomic_loadMODE instruction pattern: Standard Names. (line 1746) 45862* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 1808) 45863* atomic_nandMODE instruction pattern: Standard Names. (line 1779) 45864* atomic_or_fetchMODE instruction pattern: Standard Names. (line 1808) 45865* atomic_orMODE instruction pattern: Standard Names. (line 1779) 45866* atomic_storeMODE instruction pattern: Standard Names. (line 1756) 45867* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 1808) 45868* atomic_subMODE instruction pattern: Standard Names. (line 1779) 45869* atomic_test_and_set instruction pattern: Standard Names. (line 1825) 45870* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 1808) 45871* atomic_xorMODE instruction pattern: Standard Names. (line 1779) 45872* attr <1>: Tagging Insns. (line 54) 45873* attr: Expressions. (line 165) 45874* attr_flag: Expressions. (line 140) 45875* attribute expressions: Expressions. (line 6) 45876* attribute specifications: Attr Example. (line 6) 45877* attribute specifications example: Attr Example. (line 6) 45878* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 179) 45879* attributes: Attributes. (line 6) 45880* attributes, defining: Defining Attributes. 45881 (line 6) 45882* attributes, target-specific: Target Attributes. (line 6) 45883* autoincrement addressing, availability: Portability. (line 21) 45884* autoincrement/decrement addressing: Simple Constraints. (line 30) 45885* automata_option: Processor pipeline description. 45886 (line 305) 45887* automaton based pipeline description: Processor pipeline description. 45888 (line 6) 45889* automaton based scheduler: Processor pipeline description. 45890 (line 6) 45891* AVOID_CCMODE_COPIES: Values in Registers. 45892 (line 153) 45893* backslash: Output Template. (line 46) 45894* barrier: Insns. (line 166) 45895* barrier and /f: Flags. (line 107) 45896* barrier and /v: Flags. (line 44) 45897* BASE_REG_CLASS: Register Classes. (line 114) 45898* basic block: Basic Blocks. (line 6) 45899* Basic Statements: Basic Statements. (line 6) 45900* basic-block.h: Control Flow. (line 6) 45901* BASIC_BLOCK: Basic Blocks. (line 14) 45902* basic_block: Basic Blocks. (line 6) 45903* BB_HEAD, BB_END: Maintaining the CFG. 45904 (line 77) 45905* bb_seq: GIMPLE sequences. (line 73) 45906* BIGGEST_ALIGNMENT: Storage Layout. (line 169) 45907* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 190) 45908* BImode: Machine Modes. (line 22) 45909* BIND_EXPR: Unary and Binary Expressions. 45910 (line 6) 45911* BINFO_TYPE: Classes. (line 6) 45912* bit-fields: Bit-Fields. (line 6) 45913* BIT_AND_EXPR: Unary and Binary Expressions. 45914 (line 6) 45915* BIT_IOR_EXPR: Unary and Binary Expressions. 45916 (line 6) 45917* BIT_NOT_EXPR: Unary and Binary Expressions. 45918 (line 6) 45919* BIT_XOR_EXPR: Unary and Binary Expressions. 45920 (line 6) 45921* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 394) 45922* BITS_BIG_ENDIAN: Storage Layout. (line 12) 45923* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 45924* BITS_PER_UNIT: Storage Layout. (line 51) 45925* BITS_PER_WORD: Storage Layout. (line 56) 45926* bitwise complement: Arithmetic. (line 154) 45927* bitwise exclusive-or: Arithmetic. (line 168) 45928* bitwise inclusive-or: Arithmetic. (line 163) 45929* bitwise logical-and: Arithmetic. (line 158) 45930* BLKmode: Machine Modes. (line 183) 45931* BLKmode, and function return values: Calls. (line 23) 45932* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 45933 (line 29) 45934* BLOCK_REG_PADDING: Register Arguments. (line 230) 45935* blockage instruction pattern: Standard Names. (line 1578) 45936* Blocks: Blocks. (line 6) 45937* bool: Misc. (line 857) 45938* BOOL_TYPE_SIZE: Type Layout. (line 44) 45939* BOOLEAN_TYPE: Types. (line 6) 45940* branch prediction: Profile information. 45941 (line 24) 45942* BRANCH_COST: Costs. (line 105) 45943* break_out_memory_refs: Addressing Modes. (line 135) 45944* BREAK_STMT: Statements for C++. (line 6) 45945* BSS_SECTION_ASM_OP: Sections. (line 68) 45946* bswap: Arithmetic. (line 247) 45947* bswapM2 instruction pattern: Standard Names. (line 528) 45948* btruncM2 instruction pattern: Standard Names. (line 636) 45949* build0: Macros and Functions. 45950 (line 16) 45951* build1: Macros and Functions. 45952 (line 17) 45953* build2: Macros and Functions. 45954 (line 18) 45955* build3: Macros and Functions. 45956 (line 19) 45957* build4: Macros and Functions. 45958 (line 20) 45959* build5: Macros and Functions. 45960 (line 21) 45961* build6: Macros and Functions. 45962 (line 22) 45963* builtin_longjmp instruction pattern: Standard Names. (line 1475) 45964* builtin_setjmp_receiver instruction pattern: Standard Names. 45965 (line 1465) 45966* builtin_setjmp_setup instruction pattern: Standard Names. (line 1454) 45967* byte_mode: Machine Modes. (line 336) 45968* BYTES_BIG_ENDIAN: Storage Layout. (line 24) 45969* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221) 45970* C statements for assembler output: Output Statement. (line 6) 45971* C99 math functions, implicit usage: Library Calls. (line 70) 45972* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 137) 45973* c_register_pragma: Misc. (line 402) 45974* c_register_pragma_with_expansion: Misc. (line 404) 45975* call <1>: Side Effects. (line 92) 45976* call: Flags. (line 221) 45977* call instruction pattern: Standard Names. (line 1107) 45978* call usage: Calls. (line 10) 45979* call, in call_insn: Flags. (line 33) 45980* call, in mem: Flags. (line 81) 45981* call-clobbered register: Register Basics. (line 35) 45982* call-saved register: Register Basics. (line 35) 45983* call-used register: Register Basics. (line 35) 45984* CALL_EXPR: Unary and Binary Expressions. 45985 (line 6) 45986* call_insn: Insns. (line 95) 45987* call_insn and /c: Flags. (line 33) 45988* call_insn and /f: Flags. (line 107) 45989* call_insn and /i: Flags. (line 24) 45990* call_insn and /j: Flags. (line 161) 45991* call_insn and /s: Flags. (line 49) 45992* call_insn and /u: Flags. (line 19) 45993* call_insn and /u or /i: Flags. (line 29) 45994* call_insn and /v: Flags. (line 44) 45995* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 45996* call_pop instruction pattern: Standard Names. (line 1135) 45997* CALL_POPS_ARGS: Stack Arguments. (line 139) 45998* CALL_REALLY_USED_REGISTERS: Register Basics. (line 46) 45999* CALL_USED_REGISTERS: Register Basics. (line 35) 46000* call_used_regs: Register Basics. (line 59) 46001* call_value instruction pattern: Standard Names. (line 1127) 46002* call_value_pop instruction pattern: Standard Names. (line 1135) 46003* CALLER_SAVE_PROFITABLE: Caller Saves. (line 11) 46004* calling conventions: Stack and Calling. (line 6) 46005* calling functions in RTL: Calls. (line 6) 46006* can_create_pseudo_p: Standard Names. (line 75) 46007* can_fallthru: Basic Blocks. (line 67) 46008* canadian: Configure Terms. (line 6) 46009* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 538) 46010* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 46011 (line 280) 46012* canonicalization of instructions: Insn Canonicalizations. 46013 (line 6) 46014* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 46015 (line 1306) 46016* CASE_VECTOR_MODE: Misc. (line 27) 46017* CASE_VECTOR_PC_RELATIVE: Misc. (line 40) 46018* CASE_VECTOR_SHORTEN_MODE: Misc. (line 31) 46019* casesi instruction pattern: Standard Names. (line 1229) 46020* cbranchMODE4 instruction pattern: Standard Names. (line 1096) 46021* cc0 <1>: CC0 Condition Codes. 46022 (line 6) 46023* cc0: Regs and Memory. (line 307) 46024* cc0, RTL sharing: Sharing. (line 27) 46025* cc0_rtx: Regs and Memory. (line 333) 46026* CC1_SPEC: Driver. (line 56) 46027* CC1PLUS_SPEC: Driver. (line 64) 46028* cc_status: CC0 Condition Codes. 46029 (line 6) 46030* CC_STATUS_MDEP: CC0 Condition Codes. 46031 (line 17) 46032* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 46033 (line 23) 46034* CCmode <1>: MODE_CC Condition Codes. 46035 (line 6) 46036* CCmode: Machine Modes. (line 176) 46037* CDImode: Machine Modes. (line 202) 46038* CEIL_DIV_EXPR: Unary and Binary Expressions. 46039 (line 6) 46040* CEIL_MOD_EXPR: Unary and Binary Expressions. 46041 (line 6) 46042* ceilM2 instruction pattern: Standard Names. (line 652) 46043* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226) 46044* CFG verification: Maintaining the CFG. 46045 (line 119) 46046* CFG, Control Flow Graph: Control Flow. (line 6) 46047* cfghooks.h: Maintaining the CFG. 46048 (line 6) 46049* cgraph_finalize_function: Parsing pass. (line 52) 46050* chain_circular: GTY Options. (line 196) 46051* chain_next: GTY Options. (line 196) 46052* chain_prev: GTY Options. (line 196) 46053* change_address: Standard Names. (line 47) 46054* CHAR_TYPE_SIZE: Type Layout. (line 39) 46055* check_stack instruction pattern: Standard Names. (line 1393) 46056* CHImode: Machine Modes. (line 202) 46057* class definitions, register: Register Classes. (line 6) 46058* class preference constraints: Class Preferences. (line 6) 46059* class, scope: Classes. (line 6) 46060* CLASS_MAX_NREGS: Register Classes. (line 526) 46061* CLASS_TYPE_P: Types for C++. (line 65) 46062* classes of RTX codes: RTL Classes. (line 6) 46063* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 46064* CLASSTYPE_HAS_MUTABLE: Classes. (line 85) 46065* CLASSTYPE_NON_POD_P: Classes. (line 90) 46066* CLEANUP_DECL: Statements for C++. (line 6) 46067* CLEANUP_EXPR: Statements for C++. (line 6) 46068* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 46069 (line 6) 46070* CLEANUP_STMT: Statements for C++. (line 6) 46071* Cleanups: Cleanups. (line 6) 46072* CLEAR_BY_PIECES_P: Costs. (line 188) 46073* clear_cache instruction pattern: Standard Names. (line 1885) 46074* CLEAR_INSN_CACHE: Trampolines. (line 99) 46075* CLEAR_RATIO: Costs. (line 176) 46076* clobber: Side Effects. (line 106) 46077* clrsb: Arithmetic. (line 216) 46078* clz: Arithmetic. (line 223) 46079* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 305) 46080* clzM2 instruction pattern: Standard Names. (line 717) 46081* cmpmemM instruction pattern: Standard Names. (line 850) 46082* cmpstrM instruction pattern: Standard Names. (line 829) 46083* cmpstrnM instruction pattern: Standard Names. (line 816) 46084* code generation RTL sequences: Expander Definitions. 46085 (line 6) 46086* code iterators in .md files: Code Iterators. (line 6) 46087* CODE_LABEL: Basic Blocks. (line 50) 46088* code_label: Insns. (line 125) 46089* code_label and /i: Flags. (line 59) 46090* code_label and /v: Flags. (line 44) 46091* CODE_LABEL_NUMBER: Insns. (line 125) 46092* codes, RTL expression: RTL Objects. (line 47) 46093* COImode: Machine Modes. (line 202) 46094* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 46095* COLLECT_EXPORT_LIST: Misc. (line 756) 46096* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 46097 (line 44) 46098* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 46099 (line 33) 46100* commit_edge_insertions: Maintaining the CFG. 46101 (line 107) 46102* compare: Arithmetic. (line 43) 46103* compare, canonicalization of: Insn Canonicalizations. 46104 (line 37) 46105* comparison_operator: Machine-Independent Predicates. 46106 (line 111) 46107* compiler passes and files: Passes. (line 6) 46108* complement, bitwise: Arithmetic. (line 154) 46109* COMPLEX_CST: Constant expressions. 46110 (line 6) 46111* COMPLEX_EXPR: Unary and Binary Expressions. 46112 (line 6) 46113* COMPLEX_TYPE: Types. (line 6) 46114* COMPONENT_REF: Storage References. (line 6) 46115* Compound Expressions: Compound Expressions. 46116 (line 6) 46117* Compound Lvalues: Compound Lvalues. (line 6) 46118* COMPOUND_EXPR: Unary and Binary Expressions. 46119 (line 6) 46120* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 46121 (line 6) 46122* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 46123 (line 375) 46124* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 46125 (line 375) 46126* computed jump: Edges. (line 128) 46127* computing the length of an insn: Insn Lengths. (line 6) 46128* concat: Regs and Memory. (line 385) 46129* concatn: Regs and Memory. (line 391) 46130* cond: Comparisons. (line 90) 46131* cond and attributes: Expressions. (line 37) 46132* cond_exec: Side Effects. (line 254) 46133* COND_EXPR: Unary and Binary Expressions. 46134 (line 6) 46135* condition code register: Regs and Memory. (line 307) 46136* condition code status: Condition Code. (line 6) 46137* condition codes: Comparisons. (line 20) 46138* conditional execution: Conditional Execution. 46139 (line 6) 46140* Conditional Expressions: Conditional Expressions. 46141 (line 6) 46142* conditions, in patterns: Patterns. (line 43) 46143* configuration file <1>: Host Misc. (line 6) 46144* configuration file: Filesystem. (line 6) 46145* configure terms: Configure Terms. (line 6) 46146* CONJ_EXPR: Unary and Binary Expressions. 46147 (line 6) 46148* const: Constants. (line 110) 46149* CONST0_RTX: Constants. (line 130) 46150* const0_rtx: Constants. (line 21) 46151* CONST1_RTX: Constants. (line 130) 46152* const1_rtx: Constants. (line 21) 46153* CONST2_RTX: Constants. (line 130) 46154* const2_rtx: Constants. (line 21) 46155* CONST_DECL: Declarations. (line 6) 46156* const_double: Constants. (line 37) 46157* const_double, RTL sharing: Sharing. (line 29) 46158* CONST_DOUBLE_LOW: Constants. (line 50) 46159* CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69) 46160* CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54) 46161* const_double_operand: Machine-Independent Predicates. 46162 (line 21) 46163* const_fixed: Constants. (line 63) 46164* const_int: Constants. (line 8) 46165* const_int and attribute tests: Expressions. (line 47) 46166* const_int and attributes: Expressions. (line 10) 46167* const_int, RTL sharing: Sharing. (line 23) 46168* const_int_operand: Machine-Independent Predicates. 46169 (line 16) 46170* CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49) 46171* CONST_OK_FOR_LETTER_P: Old Constraints. (line 40) 46172* const_string: Constants. (line 82) 46173* const_string and attributes: Expressions. (line 20) 46174* const_true_rtx: Constants. (line 31) 46175* const_vector: Constants. (line 70) 46176* const_vector, RTL sharing: Sharing. (line 32) 46177* constant attributes: Constant Attributes. 46178 (line 6) 46179* constant definitions: Constant Definitions. 46180 (line 6) 46181* CONSTANT_ADDRESS_P: Addressing Modes. (line 29) 46182* CONSTANT_ALIGNMENT: Storage Layout. (line 237) 46183* CONSTANT_P: Addressing Modes. (line 36) 46184* CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 46185* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 65) 46186* constants in constraints: Simple Constraints. (line 70) 46187* constm1_rtx: Constants. (line 21) 46188* constraint modifier characters: Modifiers. (line 6) 46189* constraint, matching: Simple Constraints. (line 142) 46190* CONSTRAINT_LEN: Old Constraints. (line 12) 46191* constraint_num: C Constraint Interface. 46192 (line 38) 46193* constraint_satisfied_p: C Constraint Interface. 46194 (line 54) 46195* constraints: Constraints. (line 6) 46196* constraints, defining: Define Constraints. (line 6) 46197* constraints, defining, obsolete method: Old Constraints. (line 6) 46198* constraints, machine specific: Machine Constraints. 46199 (line 6) 46200* constraints, testing: C Constraint Interface. 46201 (line 6) 46202* CONSTRUCTOR: Unary and Binary Expressions. 46203 (line 6) 46204* constructors, automatic calls: Collect2. (line 15) 46205* constructors, output of: Initialization. (line 6) 46206* container: Containers. (line 6) 46207* CONTINUE_STMT: Statements for C++. (line 6) 46208* contributors: Contributors. (line 6) 46209* controlling register usage: Register Basics. (line 73) 46210* controlling the compilation driver: Driver. (line 6) 46211* conventions, run-time: Interface. (line 6) 46212* conversions: Conversions. (line 6) 46213* CONVERT_EXPR: Unary and Binary Expressions. 46214 (line 6) 46215* copy_rtx: Addressing Modes. (line 190) 46216* copy_rtx_if_shared: Sharing. (line 64) 46217* copysignM3 instruction pattern: Standard Names. (line 698) 46218* cosM2 instruction pattern: Standard Names. (line 564) 46219* costs of instructions: Costs. (line 6) 46220* CP_INTEGRAL_TYPE: Types for C++. (line 57) 46221* cp_namespace_decls: Namespaces. (line 49) 46222* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 46223* CP_TYPE_CONST_P: Types for C++. (line 24) 46224* cp_type_quals: Types for C++. (line 6) 46225* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 46226* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 46227* CPLUSPLUS_CPP_SPEC: Driver. (line 51) 46228* CPP_SPEC: Driver. (line 44) 46229* CQImode: Machine Modes. (line 202) 46230* cross compilation and floating point: Floating Point. (line 6) 46231* CRT_CALL_STATIC_FUNCTION: Sections. (line 121) 46232* crtl->args.pops_args: Function Entry. (line 106) 46233* crtl->args.pretend_args_size: Function Entry. (line 112) 46234* crtl->outgoing_args_size: Stack Arguments. (line 48) 46235* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 46236* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 46237* CSImode: Machine Modes. (line 202) 46238* cstoreMODE4 instruction pattern: Standard Names. (line 1057) 46239* CTImode: Machine Modes. (line 202) 46240* ctrapMM4 instruction pattern: Standard Names. (line 1547) 46241* ctz: Arithmetic. (line 231) 46242* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 306) 46243* ctzM2 instruction pattern: Standard Names. (line 726) 46244* CUMULATIVE_ARGS: Register Arguments. (line 128) 46245* current_function_is_leaf: Leaf Functions. (line 51) 46246* current_function_uses_only_leaf_regs: Leaf Functions. (line 51) 46247* current_insn_predicate: Conditional Execution. 46248 (line 26) 46249* DAmode: Machine Modes. (line 152) 46250* data bypass: Processor pipeline description. 46251 (line 106) 46252* data dependence delays: Processor pipeline description. 46253 (line 6) 46254* Data Dependency Analysis: Dependency analysis. 46255 (line 6) 46256* data structures: Per-Function Data. (line 6) 46257* DATA_ALIGNMENT: Storage Layout. (line 224) 46258* DATA_SECTION_ASM_OP: Sections. (line 53) 46259* DBR_OUTPUT_SEQEND: Instruction Output. (line 135) 46260* dbr_sequence_length: Instruction Output. (line 134) 46261* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103) 46262* DBX_CONTIN_CHAR: DBX Options. (line 66) 46263* DBX_CONTIN_LENGTH: DBX Options. (line 56) 46264* DBX_DEBUGGING_INFO: DBX Options. (line 9) 46265* DBX_FUNCTION_FIRST: DBX Options. (line 97) 46266* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109) 46267* DBX_NO_XREFS: DBX Options. (line 50) 46268* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34) 46269* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9) 46270* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 46271 (line 42) 46272* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 9) 46273* DBX_REGISTER_NUMBER: All Debuggers. (line 9) 46274* DBX_REGPARM_STABS_CODE: DBX Options. (line 87) 46275* DBX_REGPARM_STABS_LETTER: DBX Options. (line 92) 46276* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82) 46277* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73) 46278* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78) 46279* DBX_USE_BINCL: DBX Options. (line 115) 46280* DCmode: Machine Modes. (line 197) 46281* DDmode: Machine Modes. (line 90) 46282* De Morgan's law: Insn Canonicalizations. 46283 (line 52) 46284* dead_or_set_p: define_peephole. (line 65) 46285* debug_expr: Debug Information. (line 22) 46286* DEBUG_EXPR_DECL: Declarations. (line 6) 46287* debug_insn: Insns. (line 245) 46288* DEBUG_SYMS_TEXT: DBX Options. (line 25) 46289* DEBUGGER_ARG_OFFSET: All Debuggers. (line 37) 46290* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28) 46291* decimal float library: Decimal float library routines. 46292 (line 6) 46293* DECL_ALIGN: Declarations. (line 6) 46294* DECL_ANTICIPATED: Functions for C++. (line 42) 46295* DECL_ARGUMENTS: Function Basics. (line 36) 46296* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 46297* DECL_ARTIFICIAL <1>: Function Properties. 46298 (line 47) 46299* DECL_ARTIFICIAL <2>: Function Basics. (line 6) 46300* DECL_ARTIFICIAL: Working with declarations. 46301 (line 24) 46302* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 46303* DECL_ATTRIBUTES: Attributes. (line 22) 46304* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 46305* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 46306* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 46307* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 46308* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 46309* DECL_CONTEXT: Namespaces. (line 31) 46310* DECL_CONV_FN_P: Functions for C++. (line 105) 46311* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 46312* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 46313* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 46314* DECL_EXTERNAL <1>: Function Properties. 46315 (line 25) 46316* DECL_EXTERNAL: Declarations. (line 6) 46317* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 46318* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 46319 (line 61) 46320* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 46321* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 46322 (line 55) 46323* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 46324* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 46325* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 46326* DECL_INITIAL <1>: Function Basics. (line 51) 46327* DECL_INITIAL: Declarations. (line 6) 46328* DECL_LINKONCE_P: Functions for C++. (line 50) 46329* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 46330* DECL_MAIN_P: Functions for C++. (line 34) 46331* DECL_NAME <1>: Namespaces. (line 20) 46332* DECL_NAME <2>: Function Basics. (line 6) 46333* DECL_NAME: Working with declarations. 46334 (line 7) 46335* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 46336* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 46337* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 46338* DECL_NONCONVERTING_P: Functions for C++. (line 80) 46339* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 46340* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 46341* DECL_PURE_P: Function Properties. 46342 (line 40) 46343* DECL_RESULT: Function Basics. (line 41) 46344* DECL_SAVED_TREE: Function Basics. (line 44) 46345* DECL_SIZE: Declarations. (line 6) 46346* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 46347* DECL_STMT: Statements for C++. (line 6) 46348* DECL_STMT_DECL: Statements for C++. (line 6) 46349* DECL_THUNK_P: Functions for C++. (line 116) 46350* DECL_VIRTUAL_P: Function Properties. 46351 (line 44) 46352* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 46353* declaration: Declarations. (line 6) 46354* declarations, RTL: RTL Declarations. (line 6) 46355* DECLARE_LIBRARY_RENAMES: Library Calls. (line 9) 46356* decrement_and_branch_until_zero instruction pattern: Standard Names. 46357 (line 1267) 46358* default: GTY Options. (line 82) 46359* default_file_start: File Framework. (line 8) 46360* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18) 46361* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 35) 46362* DEFAULT_SIGNED_CHAR: Type Layout. (line 161) 46363* define_address_constraint: Define Constraints. (line 107) 46364* define_asm_attributes: Tagging Insns. (line 73) 46365* define_attr: Defining Attributes. 46366 (line 6) 46367* define_automaton: Processor pipeline description. 46368 (line 53) 46369* define_bypass: Processor pipeline description. 46370 (line 197) 46371* define_c_enum: Constant Definitions. 46372 (line 49) 46373* define_code_attr: Code Iterators. (line 6) 46374* define_code_iterator: Code Iterators. (line 6) 46375* define_cond_exec: Conditional Execution. 46376 (line 13) 46377* define_constants: Constant Definitions. 46378 (line 6) 46379* define_constraint: Define Constraints. (line 48) 46380* define_cpu_unit: Processor pipeline description. 46381 (line 68) 46382* define_delay: Delay Slots. (line 25) 46383* define_enum: Constant Definitions. 46384 (line 118) 46385* define_enum_attr <1>: Constant Definitions. 46386 (line 136) 46387* define_enum_attr: Defining Attributes. 46388 (line 76) 46389* define_expand: Expander Definitions. 46390 (line 11) 46391* define_insn: Patterns. (line 6) 46392* define_insn example: Example. (line 6) 46393* define_insn_and_split: Insn Splitting. (line 170) 46394* define_insn_reservation: Processor pipeline description. 46395 (line 106) 46396* define_int_attr: Int Iterators. (line 6) 46397* define_int_iterator: Int Iterators. (line 6) 46398* define_memory_constraint: Define Constraints. (line 88) 46399* define_mode_attr: Substitutions. (line 6) 46400* define_mode_iterator: Defining Mode Iterators. 46401 (line 6) 46402* define_peephole: define_peephole. (line 6) 46403* define_peephole2: define_peephole2. (line 6) 46404* define_predicate: Defining Predicates. 46405 (line 6) 46406* define_query_cpu_unit: Processor pipeline description. 46407 (line 90) 46408* define_register_constraint: Define Constraints. (line 28) 46409* define_reservation: Processor pipeline description. 46410 (line 186) 46411* define_special_predicate: Defining Predicates. 46412 (line 6) 46413* define_split: Insn Splitting. (line 32) 46414* define_subst <1>: Subst Iterators. (line 6) 46415* define_subst <2>: Define Subst Output Template. 46416 (line 6) 46417* define_subst <3>: Define Subst Pattern Matching. 46418 (line 6) 46419* define_subst <4>: Define Subst Example. 46420 (line 6) 46421* define_subst: Define Subst. (line 6) 46422* define_subst_attr: Subst Iterators. (line 6) 46423* defining attributes and their values: Defining Attributes. 46424 (line 6) 46425* defining constraints: Define Constraints. (line 6) 46426* defining constraints, obsolete method: Old Constraints. (line 6) 46427* defining jump instruction patterns: Jump Patterns. (line 6) 46428* defining looping instruction patterns: Looping Patterns. (line 6) 46429* defining peephole optimizers: Peephole Definitions. 46430 (line 6) 46431* defining predicates: Defining Predicates. 46432 (line 6) 46433* defining RTL sequences for code generation: Expander Definitions. 46434 (line 6) 46435* delay slots, defining: Delay Slots. (line 6) 46436* deletable: GTY Options. (line 150) 46437* DELETE_IF_ORDINARY: Filesystem. (line 79) 46438* Dependent Patterns: Dependent Patterns. (line 6) 46439* desc: GTY Options. (line 82) 46440* destructors, output of: Initialization. (line 6) 46441* deterministic finite state automaton: Processor pipeline description. 46442 (line 6) 46443* DF_SIZE: Type Layout. (line 137) 46444* DFmode: Machine Modes. (line 73) 46445* digits in constraint: Simple Constraints. (line 130) 46446* DImode: Machine Modes. (line 45) 46447* DIR_SEPARATOR: Filesystem. (line 18) 46448* DIR_SEPARATOR_2: Filesystem. (line 19) 46449* directory options .md: Including Patterns. (line 44) 46450* disabling certain registers: Register Basics. (line 73) 46451* dispatch table: Dispatch Tables. (line 8) 46452* div: Arithmetic. (line 116) 46453* div and attributes: Expressions. (line 85) 46454* division: Arithmetic. (line 116) 46455* divM3 instruction pattern: Standard Names. (line 269) 46456* divmodM4 instruction pattern: Standard Names. (line 490) 46457* DO_BODY: Statements for C++. (line 6) 46458* DO_COND: Statements for C++. (line 6) 46459* DO_STMT: Statements for C++. (line 6) 46460* DOLLARS_IN_IDENTIFIERS: Misc. (line 446) 46461* doloop_begin instruction pattern: Standard Names. (line 1299) 46462* doloop_end instruction pattern: Standard Names. (line 1277) 46463* DONE: Expander Definitions. 46464 (line 77) 46465* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 46466 (line 79) 46467* DOUBLE_TYPE_SIZE: Type Layout. (line 53) 46468* DQmode: Machine Modes. (line 115) 46469* driver: Driver. (line 6) 46470* DRIVER_SELF_SPECS: Driver. (line 9) 46471* DUMPFILE_FORMAT: Filesystem. (line 67) 46472* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 50) 46473* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13) 46474* DWARF2_FRAME_INFO: SDB and DWARF. (line 30) 46475* DWARF2_FRAME_REG_OUT: Frame Registers. (line 150) 46476* DWARF2_UNWIND_INFO: Exception Region Output. 46477 (line 40) 46478* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152) 46479* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 46480 (line 91) 46481* DWARF_FRAME_REGISTERS: Frame Registers. (line 110) 46482* DWARF_FRAME_REGNUM: Frame Registers. (line 142) 46483* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 46484* DWARF_ZERO_REG: Frame Layout. (line 163) 46485* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92) 46486* E in constraint: Simple Constraints. (line 89) 46487* earlyclobber operand: Modifiers. (line 25) 46488* edge: Edges. (line 6) 46489* edge in the flow graph: Edges. (line 6) 46490* edge iterators: Edges. (line 15) 46491* edge splitting: Maintaining the CFG. 46492 (line 107) 46493* EDGE_ABNORMAL: Edges. (line 128) 46494* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 172) 46495* EDGE_ABNORMAL, EDGE_EH: Edges. (line 96) 46496* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122) 46497* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86) 46498* EDOM, implicit usage: Library Calls. (line 52) 46499* EH_FRAME_IN_DATA_SECTION: Exception Region Output. 46500 (line 20) 46501* EH_FRAME_SECTION_NAME: Exception Region Output. 46502 (line 10) 46503* eh_return instruction pattern: Standard Names. (line 1481) 46504* EH_RETURN_DATA_REGNO: Exception Handling. (line 7) 46505* EH_RETURN_HANDLER_RTX: Exception Handling. (line 39) 46506* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22) 46507* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 46508 (line 29) 46509* EH_USES: Function Entry. (line 158) 46510* ei_edge: Edges. (line 43) 46511* ei_end_p: Edges. (line 27) 46512* ei_last: Edges. (line 23) 46513* ei_next: Edges. (line 35) 46514* ei_one_before_end_p: Edges. (line 31) 46515* ei_prev: Edges. (line 39) 46516* ei_safe_safe: Edges. (line 47) 46517* ei_start: Edges. (line 19) 46518* ELIMINABLE_REGS: Elimination. (line 47) 46519* ELSE_CLAUSE: Statements for C++. (line 6) 46520* Embedded C: Fixed-point fractional library routines. 46521 (line 6) 46522* EMIT_MODE_SET: Mode Switching. (line 75) 46523* Empty Statements: Empty Statements. (line 6) 46524* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 46525* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 307) 46526* Emulated TLS: Emulated TLS. (line 6) 46527* enabled: Disable Insn Alternatives. 46528 (line 6) 46529* ENDFILE_SPEC: Driver. (line 156) 46530* endianness: Portability. (line 21) 46531* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 46532* enum machine_mode: Machine Modes. (line 6) 46533* enum reg_class: Register Classes. (line 72) 46534* ENUMERAL_TYPE: Types. (line 6) 46535* enumerations: Constant Definitions. 46536 (line 49) 46537* epilogue: Function Entry. (line 6) 46538* epilogue instruction pattern: Standard Names. (line 1519) 46539* EPILOGUE_USES: Function Entry. (line 152) 46540* eq: Comparisons. (line 52) 46541* eq and attributes: Expressions. (line 85) 46542* eq_attr: Expressions. (line 106) 46543* EQ_EXPR: Unary and Binary Expressions. 46544 (line 6) 46545* equal: Comparisons. (line 52) 46546* errno, implicit usage: Library Calls. (line 64) 46547* EXACT_DIV_EXPR: Unary and Binary Expressions. 46548 (line 6) 46549* examining SSA_NAMEs: SSA. (line 216) 46550* exception handling <1>: Exception Handling. (line 6) 46551* exception handling: Edges. (line 96) 46552* exception_receiver instruction pattern: Standard Names. (line 1445) 46553* exclamation point: Multi-Alternative. (line 47) 46554* exclusion_set: Processor pipeline description. 46555 (line 224) 46556* exclusive-or, bitwise: Arithmetic. (line 168) 46557* EXIT_EXPR: Unary and Binary Expressions. 46558 (line 6) 46559* EXIT_IGNORE_STACK: Function Entry. (line 140) 46560* expander definitions: Expander Definitions. 46561 (line 6) 46562* expM2 instruction pattern: Standard Names. (line 593) 46563* EXPR_FILENAME: Working with declarations. 46564 (line 14) 46565* EXPR_LINENO: Working with declarations. 46566 (line 20) 46567* expr_list: Insns. (line 552) 46568* EXPR_STMT: Statements for C++. (line 6) 46569* EXPR_STMT_EXPR: Statements for C++. (line 6) 46570* expression: Expression trees. (line 6) 46571* expression codes: RTL Objects. (line 47) 46572* extendMN2 instruction pattern: Standard Names. (line 908) 46573* extensible constraints: Simple Constraints. (line 173) 46574* EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123) 46575* EXTRA_CONSTRAINT: Old Constraints. (line 74) 46576* EXTRA_CONSTRAINT_STR: Old Constraints. (line 95) 46577* EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100) 46578* EXTRA_SPECS: Driver. (line 183) 46579* extv instruction pattern: Standard Names. (line 999) 46580* extvM instruction pattern: Standard Names. (line 944) 46581* extvmisalignM instruction pattern: Standard Names. (line 954) 46582* extzv instruction pattern: Standard Names. (line 1017) 46583* extzvM instruction pattern: Standard Names. (line 968) 46584* extzvmisalignM instruction pattern: Standard Names. (line 971) 46585* F in constraint: Simple Constraints. (line 94) 46586* FAIL: Expander Definitions. 46587 (line 83) 46588* fall-thru: Edges. (line 69) 46589* FATAL_EXIT_CODE: Host Misc. (line 6) 46590* FDL, GNU Free Documentation License: GNU Free Documentation License. 46591 (line 6) 46592* features, optional, in system conventions: Run-time Target. 46593 (line 59) 46594* ffs: Arithmetic. (line 211) 46595* ffsM2 instruction pattern: Standard Names. (line 707) 46596* FIELD_DECL: Declarations. (line 6) 46597* file_end_indicate_exec_stack: File Framework. (line 41) 46598* files and passes of the compiler: Passes. (line 6) 46599* files, generated: Files. (line 6) 46600* final_absence_set: Processor pipeline description. 46601 (line 224) 46602* FINAL_PRESCAN_INSN: Instruction Output. (line 61) 46603* final_presence_set: Processor pipeline description. 46604 (line 224) 46605* final_sequence: Instruction Output. (line 145) 46606* FIND_BASE_TERM: Addressing Modes. (line 119) 46607* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 114) 46608* FINI_SECTION_ASM_OP: Sections. (line 99) 46609* finite state automaton minimization: Processor pipeline description. 46610 (line 305) 46611* FIRST_PARM_OFFSET: Frame Layout. (line 67) 46612* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 46613* FIRST_PSEUDO_REGISTER: Register Basics. (line 9) 46614* FIRST_STACK_REG: Stack Registers. (line 27) 46615* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 46616* fix: Conversions. (line 66) 46617* FIX_TRUNC_EXPR: Unary and Binary Expressions. 46618 (line 6) 46619* fix_truncMN2 instruction pattern: Standard Names. (line 895) 46620* fixed register: Register Basics. (line 15) 46621* fixed-point fractional library: Fixed-point fractional library routines. 46622 (line 6) 46623* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 46624 (line 6) 46625* FIXED_CST: Constant expressions. 46626 (line 6) 46627* FIXED_POINT_TYPE: Types. (line 6) 46628* FIXED_REGISTERS: Register Basics. (line 15) 46629* fixed_regs: Register Basics. (line 59) 46630* fixMN2 instruction pattern: Standard Names. (line 875) 46631* fixuns_truncMN2 instruction pattern: Standard Names. (line 899) 46632* fixunsMN2 instruction pattern: Standard Names. (line 884) 46633* flags in RTL expression: Flags. (line 6) 46634* float: Conversions. (line 58) 46635* FLOAT_EXPR: Unary and Binary Expressions. 46636 (line 6) 46637* float_extend: Conversions. (line 33) 46638* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 33) 46639* FLOAT_STORE_FLAG_VALUE: Misc. (line 287) 46640* float_truncate: Conversions. (line 53) 46641* FLOAT_TYPE_SIZE: Type Layout. (line 49) 46642* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 42) 46643* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 46644 (line 226) 46645* floating point and cross compilation: Floating Point. (line 6) 46646* floatMN2 instruction pattern: Standard Names. (line 867) 46647* floatunsMN2 instruction pattern: Standard Names. (line 871) 46648* FLOOR_DIV_EXPR: Unary and Binary Expressions. 46649 (line 6) 46650* FLOOR_MOD_EXPR: Unary and Binary Expressions. 46651 (line 6) 46652* floorM2 instruction pattern: Standard Names. (line 628) 46653* flow-insensitive alias analysis: Alias analysis. (line 6) 46654* flow-sensitive alias analysis: Alias analysis. (line 6) 46655* fma: Arithmetic. (line 111) 46656* fmaM4 instruction pattern: Standard Names. (line 279) 46657* fmodM3 instruction pattern: Standard Names. (line 546) 46658* fmsM4 instruction pattern: Standard Names. (line 286) 46659* fnmaM4 instruction pattern: Standard Names. (line 292) 46660* fnmsM4 instruction pattern: Standard Names. (line 298) 46661* FOR_BODY: Statements for C++. (line 6) 46662* FOR_COND: Statements for C++. (line 6) 46663* FOR_EXPR: Statements for C++. (line 6) 46664* FOR_INIT_STMT: Statements for C++. (line 6) 46665* FOR_STMT: Statements for C++. (line 6) 46666* FORCE_CODE_SECTION_ALIGN: Sections. (line 145) 46667* force_reg: Standard Names. (line 36) 46668* fract_convert: Conversions. (line 82) 46669* FRACT_TYPE_SIZE: Type Layout. (line 68) 46670* fractional types: Fixed-point fractional library routines. 46671 (line 6) 46672* fractMN2 instruction pattern: Standard Names. (line 917) 46673* fractunsMN2 instruction pattern: Standard Names. (line 932) 46674* frame layout: Frame Layout. (line 6) 46675* FRAME_ADDR_RTX: Frame Layout. (line 116) 46676* FRAME_GROWS_DOWNWARD: Frame Layout. (line 31) 46677* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 46678 (line 69) 46679* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212) 46680* frame_pointer_needed: Function Entry. (line 34) 46681* FRAME_POINTER_REGNUM: Frame Registers. (line 14) 46682* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 46683 (line 74) 46684* frame_pointer_rtx: Frame Registers. (line 104) 46685* frame_related: Flags. (line 229) 46686* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 46687 (line 107) 46688* frame_related, in mem: Flags. (line 85) 46689* frame_related, in reg: Flags. (line 94) 46690* frame_related, in symbol_ref: Flags. (line 165) 46691* frequency, count, BB_FREQ_BASE: Profile information. 46692 (line 30) 46693* ftruncM2 instruction pattern: Standard Names. (line 890) 46694* function <1>: Functions for C++. (line 6) 46695* function: Functions. (line 6) 46696* function call conventions: Interface. (line 6) 46697* function entry and exit: Function Entry. (line 6) 46698* function entry point, alternate function entry point: Edges. 46699 (line 181) 46700* function properties: Function Properties. 46701 (line 6) 46702* function-call insns: Calls. (line 6) 46703* FUNCTION_ARG_OFFSET: Register Arguments. (line 198) 46704* FUNCTION_ARG_PADDING: Register Arguments. (line 205) 46705* FUNCTION_ARG_REGNO_P: Register Arguments. (line 253) 46706* FUNCTION_BOUNDARY: Storage Layout. (line 166) 46707* FUNCTION_DECL <1>: Functions for C++. (line 6) 46708* FUNCTION_DECL: Functions. (line 6) 46709* FUNCTION_MODE: Misc. (line 342) 46710* FUNCTION_PROFILER: Profiling. (line 9) 46711* FUNCTION_TYPE: Types. (line 6) 46712* FUNCTION_VALUE: Scalar Return. (line 52) 46713* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 46714* functions, leaf: Leaf Functions. (line 6) 46715* fundamental type: Types. (line 6) 46716* g in constraint: Simple Constraints. (line 120) 46717* G in constraint: Simple Constraints. (line 98) 46718* garbage collector, invocation: Invoking the garbage collector. 46719 (line 6) 46720* garbage collector, troubleshooting: Troubleshooting. (line 6) 46721* GCC and portability: Portability. (line 6) 46722* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 46723* gcov_type: Profile information. 46724 (line 41) 46725* ge: Comparisons. (line 72) 46726* ge and attributes: Expressions. (line 85) 46727* GE_EXPR: Unary and Binary Expressions. 46728 (line 6) 46729* GEN_ERRNO_RTX: Library Calls. (line 65) 46730* gencodes: RTL passes. (line 18) 46731* general_operand: Machine-Independent Predicates. 46732 (line 105) 46733* GENERAL_REGS: Register Classes. (line 23) 46734* generated files: Files. (line 6) 46735* generating assembler output: Output Statement. (line 6) 46736* generating insns: RTL Template. (line 6) 46737* GENERIC <1>: GENERIC. (line 6) 46738* GENERIC: Parsing pass. (line 6) 46739* generic predicates: Machine-Independent Predicates. 46740 (line 6) 46741* genflags: RTL passes. (line 18) 46742* get_attr: Expressions. (line 101) 46743* get_attr_length: Insn Lengths. (line 46) 46744* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 333) 46745* GET_CODE: RTL Objects. (line 47) 46746* get_frame_size: Elimination. (line 34) 46747* get_insns: Insns. (line 34) 46748* get_last_insn: Insns. (line 34) 46749* GET_MODE: Machine Modes. (line 280) 46750* GET_MODE_ALIGNMENT: Machine Modes. (line 320) 46751* GET_MODE_BITSIZE: Machine Modes. (line 304) 46752* GET_MODE_CLASS: Machine Modes. (line 294) 46753* GET_MODE_FBIT: Machine Modes. (line 311) 46754* GET_MODE_IBIT: Machine Modes. (line 307) 46755* GET_MODE_MASK: Machine Modes. (line 315) 46756* GET_MODE_NAME: Machine Modes. (line 291) 46757* GET_MODE_NUNITS: Machine Modes. (line 329) 46758* GET_MODE_SIZE: Machine Modes. (line 301) 46759* GET_MODE_UNIT_SIZE: Machine Modes. (line 323) 46760* GET_MODE_WIDER_MODE: Machine Modes. (line 297) 46761* GET_RTX_CLASS: RTL Classes. (line 6) 46762* GET_RTX_FORMAT: RTL Classes. (line 131) 46763* GET_RTX_LENGTH: RTL Classes. (line 128) 46764* get_thread_pointerMODE instruction pattern: Standard Names. 46765 (line 1856) 46766* geu: Comparisons. (line 72) 46767* geu and attributes: Expressions. (line 85) 46768* GGC: Type Information. (line 6) 46769* ggc_collect: Invoking the garbage collector. 46770 (line 6) 46771* GIMPLE <1>: GIMPLE. (line 6) 46772* GIMPLE <2>: Gimplification pass. 46773 (line 6) 46774* GIMPLE: Parsing pass. (line 14) 46775* GIMPLE Exception Handling: GIMPLE Exception Handling. 46776 (line 6) 46777* GIMPLE instruction set: GIMPLE instruction set. 46778 (line 6) 46779* GIMPLE sequences: GIMPLE sequences. (line 6) 46780* GIMPLE statement iterators <1>: Maintaining the CFG. 46781 (line 34) 46782* GIMPLE statement iterators: Basic Blocks. (line 78) 46783* gimple_addresses_taken: Manipulating GIMPLE statements. 46784 (line 90) 46785* GIMPLE_ASM: GIMPLE_ASM. (line 6) 46786* gimple_asm_clear_volatile: GIMPLE_ASM. (line 63) 46787* gimple_asm_clobber_op: GIMPLE_ASM. (line 46) 46788* gimple_asm_input_op: GIMPLE_ASM. (line 30) 46789* gimple_asm_nclobbers: GIMPLE_ASM. (line 27) 46790* gimple_asm_ninputs: GIMPLE_ASM. (line 21) 46791* gimple_asm_noutputs: GIMPLE_ASM. (line 24) 46792* gimple_asm_output_op: GIMPLE_ASM. (line 38) 46793* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 50) 46794* gimple_asm_set_input_op: GIMPLE_ASM. (line 34) 46795* gimple_asm_set_output_op: GIMPLE_ASM. (line 42) 46796* gimple_asm_set_volatile: GIMPLE_ASM. (line 60) 46797* gimple_asm_string: GIMPLE_ASM. (line 53) 46798* gimple_asm_volatile_p: GIMPLE_ASM. (line 57) 46799* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 46800* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 93) 46801* gimple_assign_cast_p: Logical Operators. (line 160) 46802* gimple_assign_lhs: GIMPLE_ASSIGN. (line 51) 46803* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 54) 46804* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 57) 46805* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 60) 46806* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 64) 46807* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 67) 46808* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 71) 46809* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 74) 46810* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 46) 46811* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 41) 46812* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 78) 46813* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 81) 46814* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 85) 46815* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 89) 46816* gimple_bb: Manipulating GIMPLE statements. 46817 (line 18) 46818* GIMPLE_BIND: GIMPLE_BIND. (line 6) 46819* gimple_bind_add_seq: GIMPLE_BIND. (line 36) 46820* gimple_bind_add_stmt: GIMPLE_BIND. (line 32) 46821* gimple_bind_append_vars: GIMPLE_BIND. (line 19) 46822* gimple_bind_block: GIMPLE_BIND. (line 40) 46823* gimple_bind_body: GIMPLE_BIND. (line 23) 46824* gimple_bind_set_block: GIMPLE_BIND. (line 45) 46825* gimple_bind_set_body: GIMPLE_BIND. (line 28) 46826* gimple_bind_set_vars: GIMPLE_BIND. (line 15) 46827* gimple_bind_vars: GIMPLE_BIND. (line 12) 46828* gimple_block: Manipulating GIMPLE statements. 46829 (line 21) 46830* gimple_build_asm: GIMPLE_ASM. (line 8) 46831* gimple_build_asm_vec: GIMPLE_ASM. (line 17) 46832* gimple_build_assign: GIMPLE_ASSIGN. (line 7) 46833* gimple_build_assign_with_ops: GIMPLE_ASSIGN. (line 30) 46834* gimple_build_bind: GIMPLE_BIND. (line 8) 46835* gimple_build_call: GIMPLE_CALL. (line 8) 46836* gimple_build_call_from_tree: GIMPLE_CALL. (line 16) 46837* gimple_build_call_vec: GIMPLE_CALL. (line 25) 46838* gimple_build_catch: GIMPLE_CATCH. (line 8) 46839* gimple_build_cond: GIMPLE_COND. (line 8) 46840* gimple_build_cond_from_tree: GIMPLE_COND. (line 16) 46841* gimple_build_debug_bind: GIMPLE_DEBUG. (line 8) 46842* gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8) 46843* gimple_build_goto: GIMPLE_LABEL. (line 18) 46844* gimple_build_label: GIMPLE_LABEL. (line 7) 46845* gimple_build_nop: GIMPLE_NOP. (line 7) 46846* gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 46847 (line 8) 46848* gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 46849 (line 7) 46850* gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 46851 (line 8) 46852* gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 46853 (line 8) 46854* gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9) 46855* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7) 46856* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7) 46857* gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 46858 (line 8) 46859* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7) 46860* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7) 46861* gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 46862 (line 8) 46863* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 46864 (line 14) 46865* gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8) 46866* gimple_build_resx: GIMPLE_RESX. (line 7) 46867* gimple_build_return: GIMPLE_RETURN. (line 7) 46868* gimple_build_switch: GIMPLE_SWITCH. (line 8) 46869* gimple_build_try: GIMPLE_TRY. (line 8) 46870* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 46871 (line 7) 46872* GIMPLE_CALL: GIMPLE_CALL. (line 6) 46873* gimple_call_arg: GIMPLE_CALL. (line 66) 46874* gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 46875* gimple_call_cannot_inline_p: GIMPLE_CALL. (line 91) 46876* gimple_call_chain: GIMPLE_CALL. (line 57) 46877* gimple_call_copy_skip_args: GIMPLE_CALL. (line 98) 46878* gimple_call_fn: GIMPLE_CALL. (line 38) 46879* gimple_call_fndecl: GIMPLE_CALL. (line 46) 46880* gimple_call_lhs: GIMPLE_CALL. (line 29) 46881* gimple_call_lhs_ptr: GIMPLE_CALL. (line 32) 46882* gimple_call_mark_uninlinable: GIMPLE_CALL. (line 88) 46883* gimple_call_noreturn_p: GIMPLE_CALL. (line 94) 46884* gimple_call_num_args: GIMPLE_CALL. (line 63) 46885* gimple_call_return_type: GIMPLE_CALL. (line 54) 46886* gimple_call_set_arg: GIMPLE_CALL. (line 76) 46887* gimple_call_set_chain: GIMPLE_CALL. (line 60) 46888* gimple_call_set_fn: GIMPLE_CALL. (line 42) 46889* gimple_call_set_fndecl: GIMPLE_CALL. (line 51) 46890* gimple_call_set_lhs: GIMPLE_CALL. (line 35) 46891* gimple_call_set_tail: GIMPLE_CALL. (line 80) 46892* gimple_call_tail_p: GIMPLE_CALL. (line 85) 46893* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 46894* gimple_catch_handler: GIMPLE_CATCH. (line 20) 46895* gimple_catch_set_handler: GIMPLE_CATCH. (line 28) 46896* gimple_catch_set_types: GIMPLE_CATCH. (line 24) 46897* gimple_catch_types: GIMPLE_CATCH. (line 13) 46898* gimple_catch_types_ptr: GIMPLE_CATCH. (line 16) 46899* gimple_code: Manipulating GIMPLE statements. 46900 (line 15) 46901* GIMPLE_COND: GIMPLE_COND. (line 6) 46902* gimple_cond_code: GIMPLE_COND. (line 21) 46903* gimple_cond_false_label: GIMPLE_COND. (line 60) 46904* gimple_cond_lhs: GIMPLE_COND. (line 30) 46905* gimple_cond_make_false: GIMPLE_COND. (line 64) 46906* gimple_cond_make_true: GIMPLE_COND. (line 67) 46907* gimple_cond_rhs: GIMPLE_COND. (line 38) 46908* gimple_cond_set_code: GIMPLE_COND. (line 26) 46909* gimple_cond_set_false_label: GIMPLE_COND. (line 56) 46910* gimple_cond_set_lhs: GIMPLE_COND. (line 34) 46911* gimple_cond_set_rhs: GIMPLE_COND. (line 42) 46912* gimple_cond_set_true_label: GIMPLE_COND. (line 51) 46913* gimple_cond_true_label: GIMPLE_COND. (line 46) 46914* gimple_copy: Manipulating GIMPLE statements. 46915 (line 147) 46916* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 46917* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 46918* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 48) 46919* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 53) 46920* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 45) 46921* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 70) 46922* gimple_debug_bind_p: Logical Operators. (line 164) 46923* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 66) 46924* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 62) 46925* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 58) 46926* gimple_def_ops: Manipulating GIMPLE statements. 46927 (line 94) 46928* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 46929* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19) 46930* gimple_eh_filter_must_not_throw: GIMPLE_EH_FILTER. (line 33) 46931* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29) 46932* gimple_eh_filter_set_must_not_throw: GIMPLE_EH_FILTER. (line 37) 46933* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24) 46934* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12) 46935* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15) 46936* gimple_expr_code: Manipulating GIMPLE statements. 46937 (line 31) 46938* gimple_expr_type: Manipulating GIMPLE statements. 46939 (line 24) 46940* gimple_goto_dest: GIMPLE_LABEL. (line 21) 46941* gimple_goto_set_dest: GIMPLE_LABEL. (line 24) 46942* gimple_has_mem_ops: Manipulating GIMPLE statements. 46943 (line 72) 46944* gimple_has_ops: Manipulating GIMPLE statements. 46945 (line 69) 46946* gimple_has_volatile_ops: Manipulating GIMPLE statements. 46947 (line 134) 46948* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 46949* gimple_label_label: GIMPLE_LABEL. (line 11) 46950* gimple_label_set_label: GIMPLE_LABEL. (line 14) 46951* gimple_loaded_syms: Manipulating GIMPLE statements. 46952 (line 122) 46953* gimple_locus: Manipulating GIMPLE statements. 46954 (line 42) 46955* gimple_locus_empty_p: Manipulating GIMPLE statements. 46956 (line 48) 46957* gimple_modified_p: Manipulating GIMPLE statements. 46958 (line 130) 46959* gimple_no_warning_p: Manipulating GIMPLE statements. 46960 (line 51) 46961* GIMPLE_NOP: GIMPLE_NOP. (line 6) 46962* gimple_nop_p: GIMPLE_NOP. (line 10) 46963* gimple_num_ops <1>: Manipulating GIMPLE statements. 46964 (line 75) 46965* gimple_num_ops: Logical Operators. (line 78) 46966* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 46967 (line 6) 46968* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 46969 (line 17) 46970* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 46971 (line 24) 46972* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 46973 (line 14) 46974* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 46975 (line 21) 46976* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 46977 (line 6) 46978* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 46979 (line 12) 46980* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 46981 (line 15) 46982* gimple_omp_body: GIMPLE_OMP_PARALLEL. 46983 (line 24) 46984* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 46985 (line 6) 46986* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 46987 (line 13) 46988* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 46989 (line 17) 46990* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 46991 (line 24) 46992* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 46993 (line 28) 46994* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 46995 (line 20) 46996* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 46997 (line 31) 46998* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 46999 (line 6) 47000* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 47001 (line 13) 47002* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 47003 (line 16) 47004* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 47005 (line 21) 47006* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 47007* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 20) 47008* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 23) 47009* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 83) 47010* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 51) 47011* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 54) 47012* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 61) 47013* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 64) 47014* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 31) 47015* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 34) 47016* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 41) 47017* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 44) 47018* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 70) 47019* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 27) 47020* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 80) 47021* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 58) 47022* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 67) 47023* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 38) 47024* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 48) 47025* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 75) 47026* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 47027* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 47028* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 47029 (line 6) 47030* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 47031 (line 42) 47032* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 47033 (line 46) 47034* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 47035 (line 31) 47036* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 47037 (line 34) 47038* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 47039 (line 16) 47040* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 47041 (line 54) 47042* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 47043 (line 58) 47044* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 47045 (line 51) 47046* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 47047 (line 38) 47048* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 47049 (line 20) 47050* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 47051 (line 62) 47052* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 47053* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14) 47054* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11) 47055* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 47056* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12) 47057* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16) 47058* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 47059 (line 6) 47060* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 47061 (line 30) 47062* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 47063 (line 33) 47064* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 47065 (line 17) 47066* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 47067 (line 21) 47068* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 47069 (line 37) 47070* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 47071 (line 26) 47072* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 47073 (line 28) 47074* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 47075* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14) 47076* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17) 47077* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21) 47078* gimple_op <1>: Manipulating GIMPLE statements. 47079 (line 81) 47080* gimple_op: Logical Operators. (line 81) 47081* gimple_op_ptr: Manipulating GIMPLE statements. 47082 (line 84) 47083* gimple_ops <1>: Manipulating GIMPLE statements. 47084 (line 78) 47085* gimple_ops: Logical Operators. (line 84) 47086* GIMPLE_PHI: GIMPLE_PHI. (line 6) 47087* gimple_phi_arg: GIMPLE_PHI. (line 25) 47088* gimple_phi_capacity: GIMPLE_PHI. (line 7) 47089* gimple_phi_num_args: GIMPLE_PHI. (line 11) 47090* gimple_phi_result: GIMPLE_PHI. (line 16) 47091* gimple_phi_result_ptr: GIMPLE_PHI. (line 19) 47092* gimple_phi_set_arg: GIMPLE_PHI. (line 30) 47093* gimple_phi_set_result: GIMPLE_PHI. (line 22) 47094* gimple_plf: Manipulating GIMPLE statements. 47095 (line 66) 47096* GIMPLE_RESX: GIMPLE_RESX. (line 6) 47097* gimple_resx_region: GIMPLE_RESX. (line 13) 47098* gimple_resx_set_region: GIMPLE_RESX. (line 16) 47099* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 47100* gimple_return_retval: GIMPLE_RETURN. (line 10) 47101* gimple_return_set_retval: GIMPLE_RETURN. (line 14) 47102* gimple_seq_add_seq: GIMPLE sequences. (line 32) 47103* gimple_seq_add_stmt: GIMPLE sequences. (line 26) 47104* gimple_seq_alloc: GIMPLE sequences. (line 62) 47105* gimple_seq_copy: GIMPLE sequences. (line 67) 47106* gimple_seq_deep_copy: GIMPLE sequences. (line 37) 47107* gimple_seq_empty_p: GIMPLE sequences. (line 70) 47108* gimple_seq_first: GIMPLE sequences. (line 44) 47109* gimple_seq_init: GIMPLE sequences. (line 59) 47110* gimple_seq_last: GIMPLE sequences. (line 47) 47111* gimple_seq_reverse: GIMPLE sequences. (line 40) 47112* gimple_seq_set_first: GIMPLE sequences. (line 55) 47113* gimple_seq_set_last: GIMPLE sequences. (line 51) 47114* gimple_seq_singleton_p: GIMPLE sequences. (line 79) 47115* gimple_set_block: Manipulating GIMPLE statements. 47116 (line 39) 47117* gimple_set_def_ops: Manipulating GIMPLE statements. 47118 (line 98) 47119* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 47120 (line 138) 47121* gimple_set_locus: Manipulating GIMPLE statements. 47122 (line 45) 47123* gimple_set_op: Manipulating GIMPLE statements. 47124 (line 87) 47125* gimple_set_plf: Manipulating GIMPLE statements. 47126 (line 62) 47127* gimple_set_use_ops: Manipulating GIMPLE statements. 47128 (line 105) 47129* gimple_set_vdef_ops: Manipulating GIMPLE statements. 47130 (line 119) 47131* gimple_set_visited: Manipulating GIMPLE statements. 47132 (line 55) 47133* gimple_set_vuse_ops: Manipulating GIMPLE statements. 47134 (line 112) 47135* gimple_statement_base: Tuple representation. 47136 (line 14) 47137* gimple_statement_with_ops: Tuple representation. 47138 (line 96) 47139* gimple_stored_syms: Manipulating GIMPLE statements. 47140 (line 126) 47141* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 47142* gimple_switch_default_label: GIMPLE_SWITCH. (line 39) 47143* gimple_switch_index: GIMPLE_SWITCH. (line 24) 47144* gimple_switch_label: GIMPLE_SWITCH. (line 30) 47145* gimple_switch_num_labels: GIMPLE_SWITCH. (line 15) 47146* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 43) 47147* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 47148* gimple_switch_set_label: GIMPLE_SWITCH. (line 35) 47149* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 20) 47150* GIMPLE_TRY: GIMPLE_TRY. (line 6) 47151* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20) 47152* gimple_try_cleanup: GIMPLE_TRY. (line 27) 47153* gimple_try_eval: GIMPLE_TRY. (line 23) 47154* gimple_try_kind: GIMPLE_TRY. (line 16) 47155* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32) 47156* gimple_try_set_cleanup: GIMPLE_TRY. (line 41) 47157* gimple_try_set_eval: GIMPLE_TRY. (line 36) 47158* gimple_use_ops: Manipulating GIMPLE statements. 47159 (line 101) 47160* gimple_vdef_ops: Manipulating GIMPLE statements. 47161 (line 115) 47162* gimple_visited_p: Manipulating GIMPLE statements. 47163 (line 58) 47164* gimple_vuse_ops: Manipulating GIMPLE statements. 47165 (line 108) 47166* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 47167 (line 11) 47168* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 47169 (line 18) 47170* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 47171 (line 15) 47172* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 47173 (line 22) 47174* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 47175 (line 6) 47176* gimplification <1>: Gimplification pass. 47177 (line 6) 47178* gimplification: Parsing pass. (line 14) 47179* gimplifier: Parsing pass. (line 14) 47180* gimplify_assign: GIMPLE_ASSIGN. (line 19) 47181* gimplify_expr: Gimplification pass. 47182 (line 18) 47183* gimplify_function_tree: Gimplification pass. 47184 (line 18) 47185* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 47186* global_regs: Register Basics. (line 59) 47187* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 91) 47188* greater than: Comparisons. (line 60) 47189* gsi_after_labels: Sequence iterators. (line 76) 47190* gsi_bb: Sequence iterators. (line 83) 47191* gsi_commit_edge_inserts <1>: Maintaining the CFG. 47192 (line 107) 47193* gsi_commit_edge_inserts: Sequence iterators. (line 194) 47194* gsi_commit_one_edge_insert: Sequence iterators. (line 190) 47195* gsi_end_p <1>: Maintaining the CFG. 47196 (line 49) 47197* gsi_end_p: Sequence iterators. (line 60) 47198* gsi_for_stmt: Sequence iterators. (line 157) 47199* gsi_insert_after <1>: Maintaining the CFG. 47200 (line 61) 47201* gsi_insert_after: Sequence iterators. (line 147) 47202* gsi_insert_before <1>: Maintaining the CFG. 47203 (line 67) 47204* gsi_insert_before: Sequence iterators. (line 136) 47205* gsi_insert_on_edge <1>: Maintaining the CFG. 47206 (line 107) 47207* gsi_insert_on_edge: Sequence iterators. (line 174) 47208* gsi_insert_on_edge_immediate: Sequence iterators. (line 185) 47209* gsi_insert_seq_after: Sequence iterators. (line 154) 47210* gsi_insert_seq_before: Sequence iterators. (line 143) 47211* gsi_insert_seq_on_edge: Sequence iterators. (line 179) 47212* gsi_last <1>: Maintaining the CFG. 47213 (line 45) 47214* gsi_last: Sequence iterators. (line 50) 47215* gsi_last_bb: Sequence iterators. (line 56) 47216* gsi_link_after: Sequence iterators. (line 115) 47217* gsi_link_before: Sequence iterators. (line 105) 47218* gsi_link_seq_after: Sequence iterators. (line 110) 47219* gsi_link_seq_before: Sequence iterators. (line 99) 47220* gsi_move_after: Sequence iterators. (line 161) 47221* gsi_move_before: Sequence iterators. (line 166) 47222* gsi_move_to_bb_end: Sequence iterators. (line 171) 47223* gsi_next <1>: Maintaining the CFG. 47224 (line 53) 47225* gsi_next: Sequence iterators. (line 66) 47226* gsi_one_before_end_p: Sequence iterators. (line 63) 47227* gsi_prev <1>: Maintaining the CFG. 47228 (line 57) 47229* gsi_prev: Sequence iterators. (line 69) 47230* gsi_remove <1>: Maintaining the CFG. 47231 (line 73) 47232* gsi_remove: Sequence iterators. (line 90) 47233* gsi_replace: Sequence iterators. (line 130) 47234* gsi_seq: Sequence iterators. (line 86) 47235* gsi_split_seq_after: Sequence iterators. (line 120) 47236* gsi_split_seq_before: Sequence iterators. (line 125) 47237* gsi_start <1>: Maintaining the CFG. 47238 (line 41) 47239* gsi_start: Sequence iterators. (line 40) 47240* gsi_start_bb: Sequence iterators. (line 46) 47241* gsi_stmt: Sequence iterators. (line 72) 47242* gsi_stmt_ptr: Sequence iterators. (line 80) 47243* gt: Comparisons. (line 60) 47244* gt and attributes: Expressions. (line 85) 47245* GT_EXPR: Unary and Binary Expressions. 47246 (line 6) 47247* gtu: Comparisons. (line 64) 47248* gtu and attributes: Expressions. (line 85) 47249* GTY: Type Information. (line 6) 47250* H in constraint: Simple Constraints. (line 98) 47251* HAmode: Machine Modes. (line 144) 47252* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 436) 47253* HANDLER: Statements for C++. (line 6) 47254* HANDLER_BODY: Statements for C++. (line 6) 47255* HANDLER_PARMS: Statements for C++. (line 6) 47256* hard registers: Regs and Memory. (line 9) 47257* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 58) 47258* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 51) 47259* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20) 47260* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53) 47261* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20) 47262* HARD_REGNO_MODE_OK: Values in Registers. 47263 (line 58) 47264* HARD_REGNO_NREGS: Values in Registers. 47265 (line 11) 47266* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 47267 (line 25) 47268* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 47269 (line 43) 47270* HARD_REGNO_RENAME_OK: Values in Registers. 47271 (line 119) 47272* HAS_INIT_SECTION: Macros for Initialization. 47273 (line 19) 47274* HAS_LONG_COND_BRANCH: Misc. (line 9) 47275* HAS_LONG_UNCOND_BRANCH: Misc. (line 18) 47276* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 47277* HAVE_POST_DECREMENT: Addressing Modes. (line 12) 47278* HAVE_POST_INCREMENT: Addressing Modes. (line 11) 47279* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18) 47280* HAVE_POST_MODIFY_REG: Addressing Modes. (line 24) 47281* HAVE_PRE_DECREMENT: Addressing Modes. (line 10) 47282* HAVE_PRE_INCREMENT: Addressing Modes. (line 9) 47283* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17) 47284* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23) 47285* HCmode: Machine Modes. (line 197) 47286* HFmode: Machine Modes. (line 58) 47287* high: Constants. (line 120) 47288* HImode: Machine Modes. (line 29) 47289* HImode, in insn: Insns. (line 278) 47290* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 37) 47291* host configuration: Host Config. (line 6) 47292* host functions: Host Common. (line 6) 47293* host hooks: Host Common. (line 6) 47294* host makefile fragment: Host Fragment. (line 6) 47295* HOST_BIT_BUCKET: Filesystem. (line 51) 47296* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 47297* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12) 47298* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45) 47299* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 17) 47300* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26) 47301* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 47302* HOST_LONG_FORMAT: Host Misc. (line 45) 47303* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 47304* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 47305* HOST_PTR_PRINTF: Host Misc. (line 49) 47306* HOT_TEXT_SECTION_NAME: Sections. (line 43) 47307* HQmode: Machine Modes. (line 107) 47308* I in constraint: Simple Constraints. (line 81) 47309* i in constraint: Simple Constraints. (line 70) 47310* identifier: Identifiers. (line 6) 47311* IDENTIFIER_LENGTH: Identifiers. (line 22) 47312* IDENTIFIER_NODE: Identifiers. (line 6) 47313* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 47314* IDENTIFIER_POINTER: Identifiers. (line 17) 47315* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 47316* IEEE 754-2008: Decimal float library routines. 47317 (line 6) 47318* IF_COND: Statements for C++. (line 6) 47319* if_marked: GTY Options. (line 156) 47320* IF_STMT: Statements for C++. (line 6) 47321* if_then_else: Comparisons. (line 80) 47322* if_then_else and attributes: Expressions. (line 32) 47323* if_then_else usage: Side Effects. (line 56) 47324* IFCVT_MACHDEP_INIT: Misc. (line 560) 47325* IFCVT_MODIFY_CANCEL: Misc. (line 554) 47326* IFCVT_MODIFY_FINAL: Misc. (line 548) 47327* IFCVT_MODIFY_INSN: Misc. (line 542) 47328* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 535) 47329* IFCVT_MODIFY_TESTS: Misc. (line 524) 47330* IMAGPART_EXPR: Unary and Binary Expressions. 47331 (line 6) 47332* Immediate Uses: SSA Operands. (line 274) 47333* immediate_operand: Machine-Independent Predicates. 47334 (line 11) 47335* IMMEDIATE_PREFIX: Instruction Output. (line 155) 47336* in_struct: Flags. (line 245) 47337* in_struct, in code_label and note: Flags. (line 59) 47338* in_struct, in insn and jump_insn and call_insn: Flags. (line 49) 47339* in_struct, in insn, jump_insn and call_insn: Flags. (line 148) 47340* in_struct, in subreg: Flags. (line 187) 47341* include: Including Patterns. (line 6) 47342* INCLUDE_DEFAULTS: Driver. (line 328) 47343* inclusive-or, bitwise: Arithmetic. (line 163) 47344* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183) 47345* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 74) 47346* INCOMING_REGNO: Register Basics. (line 88) 47347* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139) 47348* INCOMING_STACK_BOUNDARY: Storage Layout. (line 161) 47349* INDEX_REG_CLASS: Register Classes. (line 143) 47350* indirect_jump instruction pattern: Standard Names. (line 1225) 47351* indirect_operand: Machine-Independent Predicates. 47352 (line 71) 47353* INDIRECT_REF: Storage References. (line 6) 47354* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 107) 47355* INIT_CUMULATIVE_ARGS: Register Arguments. (line 150) 47356* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 177) 47357* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 171) 47358* INIT_ENVIRONMENT: Driver. (line 306) 47359* INIT_EXPANDERS: Per-Function Data. (line 39) 47360* INIT_EXPR: Unary and Binary Expressions. 47361 (line 6) 47362* init_machine_status: Per-Function Data. (line 45) 47363* init_one_libfunc: Library Calls. (line 15) 47364* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 47365 (line 10) 47366* INIT_SECTION_ASM_OP: Sections. (line 91) 47367* INITIAL_ELIMINATION_OFFSET: Elimination. (line 85) 47368* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83) 47369* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 35) 47370* initialization routines: Initialization. (line 6) 47371* inlining: Target Attributes. (line 95) 47372* insert_insn_on_edge: Maintaining the CFG. 47373 (line 107) 47374* insn: Insns. (line 63) 47375* insn and /f: Flags. (line 107) 47376* insn and /j: Flags. (line 157) 47377* insn and /s: Flags. (line 49) 47378* insn and /u: Flags. (line 39) 47379* insn and /v: Flags. (line 44) 47380* insn attributes: Insn Attributes. (line 6) 47381* insn canonicalization: Insn Canonicalizations. 47382 (line 6) 47383* insn includes: Including Patterns. (line 6) 47384* insn lengths, computing: Insn Lengths. (line 6) 47385* insn notes, notes: Basic Blocks. (line 52) 47386* insn splitting: Insn Splitting. (line 6) 47387* insn-attr.h: Defining Attributes. 47388 (line 32) 47389* INSN_ANNULLED_BRANCH_P: Flags. (line 39) 47390* INSN_CODE: Insns. (line 305) 47391* INSN_DELETED_P: Flags. (line 44) 47392* INSN_FROM_TARGET_P: Flags. (line 49) 47393* insn_list: Insns. (line 552) 47394* INSN_REFERENCES_ARE_DELAYED: Misc. (line 463) 47395* INSN_SETS_ARE_DELAYED: Misc. (line 452) 47396* INSN_UID: Insns. (line 23) 47397* INSN_VAR_LOCATION: Insns. (line 245) 47398* insns: Insns. (line 6) 47399* insns, generating: RTL Template. (line 6) 47400* insns, recognizing: RTL Template. (line 6) 47401* instruction attributes: Insn Attributes. (line 6) 47402* instruction latency time: Processor pipeline description. 47403 (line 6) 47404* instruction patterns: Patterns. (line 6) 47405* instruction splitting: Insn Splitting. (line 6) 47406* insv instruction pattern: Standard Names. (line 1023) 47407* insvM instruction pattern: Standard Names. (line 975) 47408* insvmisalignM instruction pattern: Standard Names. (line 985) 47409* int iterators in .md files: Int Iterators. (line 6) 47410* INT16_TYPE: Type Layout. (line 254) 47411* INT32_TYPE: Type Layout. (line 255) 47412* INT64_TYPE: Type Layout. (line 256) 47413* INT8_TYPE: Type Layout. (line 253) 47414* INT_FAST16_TYPE: Type Layout. (line 270) 47415* INT_FAST32_TYPE: Type Layout. (line 271) 47416* INT_FAST64_TYPE: Type Layout. (line 272) 47417* INT_FAST8_TYPE: Type Layout. (line 269) 47418* INT_LEAST16_TYPE: Type Layout. (line 262) 47419* INT_LEAST32_TYPE: Type Layout. (line 263) 47420* INT_LEAST64_TYPE: Type Layout. (line 264) 47421* INT_LEAST8_TYPE: Type Layout. (line 261) 47422* INT_TYPE_SIZE: Type Layout. (line 12) 47423* INTEGER_CST: Constant expressions. 47424 (line 6) 47425* INTEGER_TYPE: Types. (line 6) 47426* Interdependence of Patterns: Dependent Patterns. (line 6) 47427* interfacing to GCC output: Interface. (line 6) 47428* interlock delays: Processor pipeline description. 47429 (line 6) 47430* intermediate representation lowering: Parsing pass. (line 14) 47431* INTMAX_TYPE: Type Layout. (line 230) 47432* INTPTR_TYPE: Type Layout. (line 277) 47433* introduction: Top. (line 6) 47434* INVOKE__main: Macros for Initialization. 47435 (line 51) 47436* ior: Arithmetic. (line 163) 47437* ior and attributes: Expressions. (line 50) 47438* ior, canonicalization of: Insn Canonicalizations. 47439 (line 52) 47440* iorM3 instruction pattern: Standard Names. (line 269) 47441* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 45) 47442* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 121) 47443* is_gimple_addressable: Logical Operators. (line 115) 47444* is_gimple_asm_val: Logical Operators. (line 119) 47445* is_gimple_assign: Logical Operators. (line 151) 47446* is_gimple_call: Logical Operators. (line 154) 47447* is_gimple_call_addr: Logical Operators. (line 122) 47448* is_gimple_constant: Logical Operators. (line 130) 47449* is_gimple_debug: Logical Operators. (line 157) 47450* is_gimple_ip_invariant: Logical Operators. (line 139) 47451* is_gimple_ip_invariant_address: Logical Operators. (line 144) 47452* is_gimple_mem_ref_addr: Logical Operators. (line 126) 47453* is_gimple_min_invariant: Logical Operators. (line 133) 47454* is_gimple_omp: GIMPLE_OMP_PARALLEL. 47455 (line 65) 47456* is_gimple_val: Logical Operators. (line 109) 47457* iterators in .md files: Iterators. (line 6) 47458* IV analysis on GIMPLE: Scalar evolutions. (line 6) 47459* IV analysis on RTL: loop-iv. (line 6) 47460* JMP_BUF_SIZE: Exception Region Output. 47461 (line 84) 47462* jump: Flags. (line 286) 47463* jump instruction pattern: Standard Names. (line 1102) 47464* jump instruction patterns: Jump Patterns. (line 6) 47465* jump instructions and set: Side Effects. (line 56) 47466* jump, in call_insn: Flags. (line 161) 47467* jump, in insn: Flags. (line 157) 47468* jump, in mem: Flags. (line 70) 47469* JUMP_ALIGN: Alignment Output. (line 9) 47470* jump_insn: Insns. (line 73) 47471* jump_insn and /f: Flags. (line 107) 47472* jump_insn and /s: Flags. (line 49) 47473* jump_insn and /u: Flags. (line 39) 47474* jump_insn and /v: Flags. (line 44) 47475* JUMP_LABEL: Insns. (line 80) 47476* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 151) 47477* Jumps: Jumps. (line 6) 47478* LABEL_ALIGN: Alignment Output. (line 58) 47479* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 27) 47480* LABEL_ALT_ENTRY_P: Insns. (line 146) 47481* LABEL_ALTERNATE_NAME: Edges. (line 181) 47482* LABEL_DECL: Declarations. (line 6) 47483* LABEL_KIND: Insns. (line 146) 47484* LABEL_NUSES: Insns. (line 142) 47485* LABEL_PRESERVE_P: Flags. (line 59) 47486* label_ref: Constants. (line 97) 47487* label_ref and /v: Flags. (line 65) 47488* label_ref, RTL sharing: Sharing. (line 35) 47489* LABEL_REF_NONLOCAL_P: Flags. (line 65) 47490* lang_hooks.gimplify_expr: Gimplification pass. 47491 (line 18) 47492* lang_hooks.parse_file: Parsing pass. (line 6) 47493* language-dependent trees: Language-dependent trees. 47494 (line 6) 47495* language-independent intermediate representation: Parsing pass. 47496 (line 14) 47497* large return values: Aggregate Return. (line 6) 47498* LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 486) 47499* LAST_STACK_REG: Stack Registers. (line 31) 47500* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 47501* lceilMN2: Standard Names. (line 693) 47502* LCSSA: LCSSA. (line 6) 47503* LD_FINI_SWITCH: Macros for Initialization. 47504 (line 29) 47505* LD_INIT_SWITCH: Macros for Initialization. 47506 (line 25) 47507* LDD_SUFFIX: Macros for Initialization. 47508 (line 122) 47509* le: Comparisons. (line 76) 47510* le and attributes: Expressions. (line 85) 47511* LE_EXPR: Unary and Binary Expressions. 47512 (line 6) 47513* leaf functions: Leaf Functions. (line 6) 47514* leaf_function_p: Standard Names. (line 1187) 47515* LEAF_REG_REMAP: Leaf Functions. (line 39) 47516* LEAF_REGISTERS: Leaf Functions. (line 25) 47517* left rotate: Arithmetic. (line 195) 47518* left shift: Arithmetic. (line 173) 47519* LEGITIMATE_PIC_OPERAND_P: PIC. (line 32) 47520* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 153) 47521* length: GTY Options. (line 50) 47522* less than: Comparisons. (line 68) 47523* less than or equal: Comparisons. (line 76) 47524* leu: Comparisons. (line 76) 47525* leu and attributes: Expressions. (line 85) 47526* lfloorMN2: Standard Names. (line 688) 47527* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 47528* LIB_SPEC: Driver. (line 108) 47529* LIBCALL_VALUE: Scalar Return. (line 56) 47530* libgcc.a: Library Calls. (line 6) 47531* LIBGCC2_CFLAGS: Target Fragment. (line 8) 47532* LIBGCC2_GNU_PREFIX: Type Layout. (line 128) 47533* LIBGCC2_HAS_DF_MODE: Type Layout. (line 109) 47534* LIBGCC2_HAS_TF_MODE: Type Layout. (line 122) 47535* LIBGCC2_HAS_XF_MODE: Type Layout. (line 116) 47536* LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 103) 47537* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 963) 47538* LIBGCC_SPEC: Driver. (line 116) 47539* library subroutine names: Library Calls. (line 6) 47540* LIBRARY_PATH_ENV: Misc. (line 503) 47541* LIMIT_RELOAD_CLASS: Register Classes. (line 300) 47542* Linear loop transformations framework: Lambda. (line 6) 47543* LINK_COMMAND_SPEC: Driver. (line 237) 47544* LINK_EH_SPEC: Driver. (line 143) 47545* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 233) 47546* LINK_LIBGCC_SPECIAL_1: Driver. (line 228) 47547* LINK_SPEC: Driver. (line 101) 47548* list: Containers. (line 6) 47549* Liveness representation: Liveness information. 47550 (line 6) 47551* lo_sum: Arithmetic. (line 24) 47552* load address instruction: Simple Constraints. (line 164) 47553* LOAD_EXTEND_OP: Misc. (line 60) 47554* load_multiple instruction pattern: Standard Names. (line 137) 47555* Local Register Allocator (LRA): RTL passes. (line 200) 47556* LOCAL_ALIGNMENT: Storage Layout. (line 250) 47557* LOCAL_CLASS_P: Classes. (line 73) 47558* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 287) 47559* LOCAL_INCLUDE_DIR: Driver. (line 313) 47560* LOCAL_LABEL_PREFIX: Instruction Output. (line 153) 47561* LOCAL_REGNO: Register Basics. (line 102) 47562* LOG_LINKS: Insns. (line 324) 47563* Logical Operators: Logical Operators. (line 6) 47564* logical-and, bitwise: Arithmetic. (line 158) 47565* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 265) 47566* logM2 instruction pattern: Standard Names. (line 601) 47567* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93) 47568* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58) 47569* LONG_FRACT_TYPE_SIZE: Type Layout. (line 73) 47570* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98) 47571* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78) 47572* LONG_LONG_TYPE_SIZE: Type Layout. (line 33) 47573* LONG_TYPE_SIZE: Type Layout. (line 22) 47574* longjmp and automatic variables: Interface. (line 52) 47575* Loop analysis: Loop representation. 47576 (line 6) 47577* Loop manipulation: Loop manipulation. (line 6) 47578* Loop querying: Loop querying. (line 6) 47579* Loop representation: Loop representation. 47580 (line 6) 47581* Loop-closed SSA form: LCSSA. (line 6) 47582* LOOP_ALIGN: Alignment Output. (line 41) 47583* LOOP_EXPR: Unary and Binary Expressions. 47584 (line 6) 47585* looping instruction patterns: Looping Patterns. (line 6) 47586* lowering, language-dependent intermediate representation: Parsing pass. 47587 (line 14) 47588* lrintMN2: Standard Names. (line 678) 47589* lroundMN2: Standard Names. (line 683) 47590* LSHIFT_EXPR: Unary and Binary Expressions. 47591 (line 6) 47592* lshiftrt: Arithmetic. (line 190) 47593* lshiftrt and attributes: Expressions. (line 85) 47594* lshrM3 instruction pattern: Standard Names. (line 520) 47595* lt: Comparisons. (line 68) 47596* lt and attributes: Expressions. (line 85) 47597* LT_EXPR: Unary and Binary Expressions. 47598 (line 6) 47599* LTGT_EXPR: Unary and Binary Expressions. 47600 (line 6) 47601* lto: LTO. (line 6) 47602* ltrans: LTO. (line 6) 47603* ltu: Comparisons. (line 68) 47604* m in constraint: Simple Constraints. (line 17) 47605* machine attributes: Target Attributes. (line 6) 47606* machine description macros: Target Macros. (line 6) 47607* machine descriptions: Machine Desc. (line 6) 47608* machine mode conversions: Conversions. (line 6) 47609* machine modes: Machine Modes. (line 6) 47610* machine specific constraints: Machine Constraints. 47611 (line 6) 47612* machine-independent predicates: Machine-Independent Predicates. 47613 (line 6) 47614* macros, target description: Target Macros. (line 6) 47615* maddMN4 instruction pattern: Standard Names. (line 443) 47616* MAKE_DECL_ONE_ONLY: Label Output. (line 250) 47617* make_safe_from: Expander Definitions. 47618 (line 151) 47619* makefile fragment: Fragments. (line 6) 47620* makefile targets: Makefile. (line 6) 47621* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 175) 47622* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 47623 (line 6) 47624* mark_hook: GTY Options. (line 171) 47625* marking roots: GGC Roots. (line 6) 47626* MASK_RETURN_ADDR: Exception Region Output. 47627 (line 35) 47628* match_dup <1>: define_peephole2. (line 28) 47629* match_dup: RTL Template. (line 73) 47630* match_dup and attributes: Insn Lengths. (line 16) 47631* match_op_dup: RTL Template. (line 163) 47632* match_operand: RTL Template. (line 16) 47633* match_operand and attributes: Expressions. (line 55) 47634* match_operator: RTL Template. (line 95) 47635* match_par_dup: RTL Template. (line 219) 47636* match_parallel: RTL Template. (line 172) 47637* match_scratch <1>: define_peephole2. (line 28) 47638* match_scratch: RTL Template. (line 58) 47639* match_test and attributes: Expressions. (line 64) 47640* matching constraint: Simple Constraints. (line 142) 47641* matching operands: Output Template. (line 49) 47642* math library: Soft float library routines. 47643 (line 6) 47644* math, in RTL: Arithmetic. (line 6) 47645* MATH_LIBRARY: Misc. (line 496) 47646* matherr: Library Calls. (line 52) 47647* MAX_BITS_PER_WORD: Storage Layout. (line 60) 47648* MAX_CONDITIONAL_EXECUTE: Misc. (line 518) 47649* MAX_FIXED_MODE_SIZE: Storage Layout. (line 433) 47650* MAX_MOVE_MAX: Misc. (line 106) 47651* MAX_OFILE_ALIGNMENT: Storage Layout. (line 212) 47652* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 43) 47653* MAX_STACK_ALIGNMENT: Storage Layout. (line 205) 47654* maxM3 instruction pattern: Standard Names. (line 304) 47655* may_trap_p, tree_could_trap_p: Edges. (line 115) 47656* maybe_undef: GTY Options. (line 179) 47657* mcount: Profiling. (line 12) 47658* MD_CAN_REDIRECT_BRANCH: Misc. (line 678) 47659* MD_EXEC_PREFIX: Driver. (line 268) 47660* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 94) 47661* MD_HANDLE_UNWABI: Exception Handling. (line 114) 47662* MD_STARTFILE_PREFIX: Driver. (line 296) 47663* MD_STARTFILE_PREFIX_1: Driver. (line 301) 47664* mem: Regs and Memory. (line 374) 47665* mem and /c: Flags. (line 81) 47666* mem and /f: Flags. (line 85) 47667* mem and /j: Flags. (line 70) 47668* mem and /u: Flags. (line 134) 47669* mem and /v: Flags. (line 76) 47670* mem, RTL sharing: Sharing. (line 40) 47671* MEM_ADDR_SPACE: Special Accessors. (line 49) 47672* MEM_ALIAS_SET: Special Accessors. (line 9) 47673* MEM_ALIGN: Special Accessors. (line 46) 47674* MEM_EXPR: Special Accessors. (line 20) 47675* MEM_KEEP_ALIAS_SET_P: Flags. (line 70) 47676* MEM_NOTRAP_P: Flags. (line 81) 47677* MEM_OFFSET: Special Accessors. (line 32) 47678* MEM_OFFSET_KNOWN_P: Special Accessors. (line 28) 47679* MEM_POINTER: Flags. (line 85) 47680* MEM_READONLY_P: Flags. (line 134) 47681* MEM_REF: Storage References. (line 6) 47682* mem_signal_fenceMODE instruction pattern: Standard Names. (line 1844) 47683* MEM_SIZE: Special Accessors. (line 40) 47684* MEM_SIZE_KNOWN_P: Special Accessors. (line 36) 47685* mem_thread_fenceMODE instruction pattern: Standard Names. (line 1836) 47686* MEM_VOLATILE_P: Flags. (line 76) 47687* memory model: Memory model. (line 6) 47688* memory reference, nonoffsettable: Simple Constraints. (line 256) 47689* memory references in constraints: Simple Constraints. (line 17) 47690* memory_barrier instruction pattern: Standard Names. (line 1585) 47691* MEMORY_MOVE_COST: Costs. (line 54) 47692* memory_operand: Machine-Independent Predicates. 47693 (line 58) 47694* METHOD_TYPE: Types. (line 6) 47695* MIN_UNITS_PER_WORD: Storage Layout. (line 70) 47696* MINIMUM_ALIGNMENT: Storage Layout. (line 300) 47697* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 183) 47698* minM3 instruction pattern: Standard Names. (line 304) 47699* minus: Arithmetic. (line 36) 47700* minus and attributes: Expressions. (line 85) 47701* minus, canonicalization of: Insn Canonicalizations. 47702 (line 27) 47703* MINUS_EXPR: Unary and Binary Expressions. 47704 (line 6) 47705* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 47706* mod: Arithmetic. (line 136) 47707* mod and attributes: Expressions. (line 85) 47708* mode classes: Machine Modes. (line 219) 47709* mode iterators in .md files: Mode Iterators. (line 6) 47710* mode switching: Mode Switching. (line 6) 47711* MODE_ACCUM: Machine Modes. (line 249) 47712* MODE_AFTER: Mode Switching. (line 49) 47713* MODE_BASE_REG_CLASS: Register Classes. (line 119) 47714* MODE_BASE_REG_REG_CLASS: Register Classes. (line 125) 47715* MODE_CC <1>: MODE_CC Condition Codes. 47716 (line 6) 47717* MODE_CC: Machine Modes. (line 268) 47718* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 133) 47719* MODE_COMPLEX_FLOAT: Machine Modes. (line 260) 47720* MODE_COMPLEX_INT: Machine Modes. (line 257) 47721* MODE_DECIMAL_FLOAT: Machine Modes. (line 237) 47722* MODE_ENTRY: Mode Switching. (line 55) 47723* MODE_EXIT: Mode Switching. (line 61) 47724* MODE_FLOAT: Machine Modes. (line 233) 47725* MODE_FRACT: Machine Modes. (line 241) 47726* MODE_FUNCTION: Machine Modes. (line 264) 47727* MODE_INT: Machine Modes. (line 225) 47728* MODE_NEEDED: Mode Switching. (line 42) 47729* MODE_PARTIAL_INT: Machine Modes. (line 229) 47730* MODE_PRIORITY_TO_MODE: Mode Switching. (line 67) 47731* MODE_RANDOM: Machine Modes. (line 273) 47732* MODE_UACCUM: Machine Modes. (line 253) 47733* MODE_UFRACT: Machine Modes. (line 245) 47734* MODES_TIEABLE_P: Values in Registers. 47735 (line 129) 47736* modifiers in constraints: Modifiers. (line 6) 47737* MODIFY_EXPR: Unary and Binary Expressions. 47738 (line 6) 47739* MODIFY_JNI_METHOD_CALL: Misc. (line 763) 47740* modM3 instruction pattern: Standard Names. (line 269) 47741* modulo scheduling: RTL passes. (line 132) 47742* MOVE_BY_PIECES_P: Costs. (line 165) 47743* MOVE_MAX: Misc. (line 101) 47744* MOVE_MAX_PIECES: Costs. (line 171) 47745* MOVE_RATIO: Costs. (line 149) 47746* movM instruction pattern: Standard Names. (line 11) 47747* movmemM instruction pattern: Standard Names. (line 750) 47748* movmisalignM instruction pattern: Standard Names. (line 126) 47749* movMODEcc instruction pattern: Standard Names. (line 1037) 47750* movstr instruction pattern: Standard Names. (line 785) 47751* movstrictM instruction pattern: Standard Names. (line 120) 47752* msubMN4 instruction pattern: Standard Names. (line 466) 47753* mulhisi3 instruction pattern: Standard Names. (line 419) 47754* mulM3 instruction pattern: Standard Names. (line 269) 47755* mulqihi3 instruction pattern: Standard Names. (line 423) 47756* mulsidi3 instruction pattern: Standard Names. (line 423) 47757* mult: Arithmetic. (line 92) 47758* mult and attributes: Expressions. (line 85) 47759* mult, canonicalization of: Insn Canonicalizations. 47760 (line 27) 47761* MULT_EXPR: Unary and Binary Expressions. 47762 (line 6) 47763* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 47764 (line 6) 47765* MULTIARCH_DIRNAME: Target Fragment. (line 170) 47766* MULTILIB_DEFAULTS: Driver. (line 253) 47767* MULTILIB_DIRNAMES: Target Fragment. (line 44) 47768* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 47769* MULTILIB_EXTRA_OPTS: Target Fragment. (line 132) 47770* MULTILIB_MATCHES: Target Fragment. (line 63) 47771* MULTILIB_OPTIONS: Target Fragment. (line 24) 47772* MULTILIB_OSDIRNAMES: Target Fragment. (line 139) 47773* MULTILIB_REQUIRED: Target Fragment. (line 82) 47774* MULTILIB_REUSE: Target Fragment. (line 103) 47775* multiple alternative constraints: Multi-Alternative. (line 6) 47776* MULTIPLE_SYMBOL_SPACES: Misc. (line 476) 47777* multiplication: Arithmetic. (line 92) 47778* multiplication with signed saturation: Arithmetic. (line 92) 47779* multiplication with unsigned saturation: Arithmetic. (line 92) 47780* n in constraint: Simple Constraints. (line 75) 47781* N_REG_CLASSES: Register Classes. (line 83) 47782* name: Identifiers. (line 6) 47783* named address spaces: Named Address Spaces. 47784 (line 6) 47785* named patterns and conditions: Patterns. (line 47) 47786* names, pattern: Standard Names. (line 6) 47787* namespace, scope: Namespaces. (line 6) 47788* NAMESPACE_DECL <1>: Namespaces. (line 6) 47789* NAMESPACE_DECL: Declarations. (line 6) 47790* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 323) 47791* ne: Comparisons. (line 56) 47792* ne and attributes: Expressions. (line 85) 47793* NE_EXPR: Unary and Binary Expressions. 47794 (line 6) 47795* nearbyintM2 instruction pattern: Standard Names. (line 660) 47796* neg: Arithmetic. (line 81) 47797* neg and attributes: Expressions. (line 85) 47798* neg, canonicalization of: Insn Canonicalizations. 47799 (line 27) 47800* NEGATE_EXPR: Unary and Binary Expressions. 47801 (line 6) 47802* negation: Arithmetic. (line 81) 47803* negation with signed saturation: Arithmetic. (line 81) 47804* negation with unsigned saturation: Arithmetic. (line 81) 47805* negM2 instruction pattern: Standard Names. (line 532) 47806* nested functions, trampolines for: Trampolines. (line 6) 47807* nested_ptr: GTY Options. (line 186) 47808* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 47809* NEXT_INSN: Insns. (line 30) 47810* NEXT_OBJC_RUNTIME: Library Calls. (line 88) 47811* nil: RTL Objects. (line 73) 47812* NM_FLAGS: Macros for Initialization. 47813 (line 111) 47814* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 26) 47815* NO_DBX_FUNCTION_END: DBX Hooks. (line 20) 47816* NO_DBX_GCC_MARKER: File Names and DBX. (line 28) 47817* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23) 47818* NO_DOLLAR_IN_LABEL: Label Output. (line 67) 47819* NO_DOT_IN_LABEL: Label Output. (line 73) 47820* NO_FUNCTION_CSE: Costs. (line 261) 47821* NO_IMPLICIT_EXTERN_C: Misc. (line 374) 47822* NO_PROFILE_COUNTERS: Profiling. (line 28) 47823* NO_REGS: Register Classes. (line 17) 47824* NON_LVALUE_EXPR: Unary and Binary Expressions. 47825 (line 6) 47826* nondeterministic finite state automaton: Processor pipeline description. 47827 (line 305) 47828* nonimmediate_operand: Machine-Independent Predicates. 47829 (line 101) 47830* nonlocal goto handler: Edges. (line 172) 47831* nonlocal_goto instruction pattern: Standard Names. (line 1417) 47832* nonlocal_goto_receiver instruction pattern: Standard Names. 47833 (line 1434) 47834* nonmemory_operand: Machine-Independent Predicates. 47835 (line 97) 47836* nonoffsettable memory reference: Simple Constraints. (line 256) 47837* nop instruction pattern: Standard Names. (line 1220) 47838* NOP_EXPR: Unary and Binary Expressions. 47839 (line 6) 47840* normal predicates: Predicates. (line 31) 47841* not: Arithmetic. (line 154) 47842* not and attributes: Expressions. (line 50) 47843* not equal: Comparisons. (line 56) 47844* not, canonicalization of: Insn Canonicalizations. 47845 (line 27) 47846* note: Insns. (line 174) 47847* note and /i: Flags. (line 59) 47848* note and /v: Flags. (line 44) 47849* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 47850* NOTE_INSN_BLOCK_BEG: Insns. (line 199) 47851* NOTE_INSN_BLOCK_END: Insns. (line 199) 47852* NOTE_INSN_DELETED: Insns. (line 189) 47853* NOTE_INSN_DELETED_LABEL: Insns. (line 194) 47854* NOTE_INSN_EH_REGION_BEG: Insns. (line 205) 47855* NOTE_INSN_EH_REGION_END: Insns. (line 205) 47856* NOTE_INSN_FUNCTION_BEG: Insns. (line 229) 47857* NOTE_INSN_LOOP_BEG: Insns. (line 213) 47858* NOTE_INSN_LOOP_CONT: Insns. (line 219) 47859* NOTE_INSN_LOOP_END: Insns. (line 213) 47860* NOTE_INSN_LOOP_VTOP: Insns. (line 223) 47861* NOTE_INSN_VAR_LOCATION: Insns. (line 233) 47862* NOTE_LINE_NUMBER: Insns. (line 174) 47863* NOTE_SOURCE_FILE: Insns. (line 174) 47864* NOTE_VAR_LOCATION: Insns. (line 233) 47865* NOTICE_UPDATE_CC: CC0 Condition Codes. 47866 (line 31) 47867* NUM_MACHINE_MODES: Machine Modes. (line 286) 47868* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 47869* Number of iterations analysis: Number of iterations. 47870 (line 6) 47871* o in constraint: Simple Constraints. (line 23) 47872* OBJC_GEN_METHOD_LABEL: Label Output. (line 452) 47873* OBJC_JBLEN: Misc. (line 958) 47874* OBJECT_FORMAT_COFF: Macros for Initialization. 47875 (line 97) 47876* OFFSET_TYPE: Types. (line 6) 47877* offsettable address: Simple Constraints. (line 23) 47878* OImode: Machine Modes. (line 51) 47879* Omega a solver for linear programming problems: Omega. (line 6) 47880* OMP_ATOMIC: OpenMP. (line 6) 47881* OMP_CLAUSE: OpenMP. (line 6) 47882* OMP_CONTINUE: OpenMP. (line 6) 47883* OMP_CRITICAL: OpenMP. (line 6) 47884* OMP_FOR: OpenMP. (line 6) 47885* OMP_MASTER: OpenMP. (line 6) 47886* OMP_ORDERED: OpenMP. (line 6) 47887* OMP_PARALLEL: OpenMP. (line 6) 47888* OMP_RETURN: OpenMP. (line 6) 47889* OMP_SECTION: OpenMP. (line 6) 47890* OMP_SECTIONS: OpenMP. (line 6) 47891* OMP_SINGLE: OpenMP. (line 6) 47892* one_cmplM2 instruction pattern: Standard Names. (line 747) 47893* operand access: Accessors. (line 6) 47894* Operand Access Routines: SSA Operands. (line 119) 47895* operand constraints: Constraints. (line 6) 47896* Operand Iterators: SSA Operands. (line 119) 47897* operand predicates: Predicates. (line 6) 47898* operand substitution: Output Template. (line 6) 47899* operands <1>: Patterns. (line 53) 47900* operands: SSA Operands. (line 6) 47901* Operands: Operands. (line 6) 47902* operator predicates: Predicates. (line 6) 47903* optc-gen.awk: Options. (line 6) 47904* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 47905* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9) 47906* option specification files: Options. (line 6) 47907* OPTION_DEFAULT_SPECS: Driver. (line 26) 47908* optional hardware or system features: Run-time Target. (line 59) 47909* options, directory search: Including Patterns. (line 44) 47910* order of register allocation: Allocation Order. (line 6) 47911* ordered_comparison_operator: Machine-Independent Predicates. 47912 (line 116) 47913* ORDERED_EXPR: Unary and Binary Expressions. 47914 (line 6) 47915* Ordering of Patterns: Pattern Ordering. (line 6) 47916* ORIGINAL_REGNO: Special Accessors. (line 54) 47917* other register constraints: Simple Constraints. (line 173) 47918* outgoing_args_size: Stack Arguments. (line 48) 47919* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 80) 47920* OUTGOING_REGNO: Register Basics. (line 95) 47921* output of assembler code: File Framework. (line 6) 47922* output statements: Output Statement. (line 6) 47923* output templates: Output Template. (line 6) 47924* output_asm_insn: Output Statement. (line 53) 47925* OUTPUT_QUOTED_STRING: File Framework. (line 108) 47926* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 21) 47927* OVERLOAD: Functions for C++. (line 6) 47928* OVERRIDE_ABI_FORMAT: Register Arguments. (line 141) 47929* OVL_CURRENT: Functions for C++. (line 6) 47930* OVL_NEXT: Functions for C++. (line 6) 47931* p in constraint: Simple Constraints. (line 164) 47932* PAD_VARARGS_DOWN: Register Arguments. (line 222) 47933* parallel: Side Effects. (line 210) 47934* param_is: GTY Options. (line 114) 47935* parameters, c++ abi: C++ ABI. (line 6) 47936* parameters, miscellaneous: Misc. (line 6) 47937* parameters, precompiled headers: PCH Target. (line 6) 47938* paramN_is: GTY Options. (line 132) 47939* parity: Arithmetic. (line 243) 47940* parityM2 instruction pattern: Standard Names. (line 741) 47941* PARM_BOUNDARY: Storage Layout. (line 140) 47942* PARM_DECL: Declarations. (line 6) 47943* PARSE_LDD_OUTPUT: Macros for Initialization. 47944 (line 127) 47945* pass_duplicate_computed_gotos: Edges. (line 162) 47946* passes and files of the compiler: Passes. (line 6) 47947* passing arguments: Interface. (line 36) 47948* PATH_SEPARATOR: Filesystem. (line 31) 47949* PATTERN: Insns. (line 294) 47950* pattern conditions: Patterns. (line 43) 47951* pattern names: Standard Names. (line 6) 47952* Pattern Ordering: Pattern Ordering. (line 6) 47953* patterns: Patterns. (line 6) 47954* pc: Regs and Memory. (line 361) 47955* pc and attributes: Insn Lengths. (line 20) 47956* pc, RTL sharing: Sharing. (line 25) 47957* PC_REGNUM: Register Basics. (line 109) 47958* pc_rtx: Regs and Memory. (line 366) 47959* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 326) 47960* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 65) 47961* PDImode: Machine Modes. (line 40) 47962* peephole optimization, RTL representation: Side Effects. (line 244) 47963* peephole optimizer definitions: Peephole Definitions. 47964 (line 6) 47965* per-function data: Per-Function Data. (line 6) 47966* percent sign: Output Template. (line 6) 47967* PHI nodes: SSA. (line 31) 47968* PHI_ARG_DEF: SSA. (line 71) 47969* PHI_ARG_EDGE: SSA. (line 68) 47970* PHI_ARG_ELT: SSA. (line 63) 47971* PHI_NUM_ARGS: SSA. (line 59) 47972* PHI_RESULT: SSA. (line 56) 47973* PIC: PIC. (line 6) 47974* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26) 47975* PIC_OFFSET_TABLE_REGNUM: PIC. (line 16) 47976* pipeline hazard recognizer: Processor pipeline description. 47977 (line 6) 47978* Plugins: Plugins. (line 6) 47979* plus: Arithmetic. (line 14) 47980* plus and attributes: Expressions. (line 85) 47981* plus, canonicalization of: Insn Canonicalizations. 47982 (line 27) 47983* PLUS_EXPR: Unary and Binary Expressions. 47984 (line 6) 47985* Pmode: Misc. (line 330) 47986* pmode_register_operand: Machine-Independent Predicates. 47987 (line 35) 47988* pointer: Types. (line 6) 47989* POINTER_PLUS_EXPR: Unary and Binary Expressions. 47990 (line 6) 47991* POINTER_SIZE: Storage Layout. (line 76) 47992* POINTER_TYPE: Types. (line 6) 47993* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 82) 47994* pop_operand: Machine-Independent Predicates. 47995 (line 88) 47996* popcount: Arithmetic. (line 239) 47997* popcountM2 instruction pattern: Standard Names. (line 735) 47998* pops_args: Function Entry. (line 106) 47999* portability: Portability. (line 6) 48000* position independent code: PIC. (line 6) 48001* post_dec: Incdec. (line 25) 48002* post_inc: Incdec. (line 30) 48003* post_modify: Incdec. (line 33) 48004* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 48005 (line 34) 48006* POSTDECREMENT_EXPR: Unary and Binary Expressions. 48007 (line 6) 48008* POSTINCREMENT_EXPR: Unary and Binary Expressions. 48009 (line 6) 48010* POWI_MAX_MULTS: Misc. (line 826) 48011* powM3 instruction pattern: Standard Names. (line 609) 48012* pragma: Misc. (line 379) 48013* pre_dec: Incdec. (line 8) 48014* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 127) 48015* pre_inc: Incdec. (line 22) 48016* pre_modify: Incdec. (line 51) 48017* PREDECREMENT_EXPR: Unary and Binary Expressions. 48018 (line 6) 48019* predefined macros: Run-time Target. (line 6) 48020* predicates: Predicates. (line 6) 48021* predicates and machine modes: Predicates. (line 31) 48022* predication: Conditional Execution. 48023 (line 6) 48024* predict.def: Profile information. 48025 (line 24) 48026* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42) 48027* PREFERRED_RELOAD_CLASS: Register Classes. (line 253) 48028* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 154) 48029* prefetch: Side Effects. (line 318) 48030* prefetch and /v: Flags. (line 214) 48031* prefetch instruction pattern: Standard Names. (line 1562) 48032* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 214) 48033* PREINCREMENT_EXPR: Unary and Binary Expressions. 48034 (line 6) 48035* presence_set: Processor pipeline description. 48036 (line 224) 48037* preserving SSA form: SSA. (line 76) 48038* preserving virtual SSA form: SSA. (line 184) 48039* pretend_args_size: Function Entry. (line 112) 48040* prev_active_insn: define_peephole. (line 60) 48041* PREV_INSN: Insns. (line 26) 48042* PRINT_OPERAND: Instruction Output. (line 96) 48043* PRINT_OPERAND_ADDRESS: Instruction Output. (line 124) 48044* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 117) 48045* probe_stack instruction pattern: Standard Names. (line 1409) 48046* probe_stack_address instruction pattern: Standard Names. (line 1402) 48047* processor functional units: Processor pipeline description. 48048 (line 6) 48049* processor pipeline description: Processor pipeline description. 48050 (line 6) 48051* product: Arithmetic. (line 92) 48052* profile feedback: Profile information. 48053 (line 14) 48054* profile representation: Profile information. 48055 (line 6) 48056* PROFILE_BEFORE_PROLOGUE: Profiling. (line 35) 48057* PROFILE_HOOK: Profiling. (line 23) 48058* profiling, code generation: Profiling. (line 6) 48059* program counter: Regs and Memory. (line 362) 48060* prologue: Function Entry. (line 6) 48061* prologue instruction pattern: Standard Names. (line 1500) 48062* PROMOTE_MODE: Storage Layout. (line 93) 48063* pseudo registers: Regs and Memory. (line 9) 48064* PSImode: Machine Modes. (line 32) 48065* PTRDIFF_TYPE: Type Layout. (line 201) 48066* purge_dead_edges <1>: Maintaining the CFG. 48067 (line 82) 48068* purge_dead_edges: Edges. (line 104) 48069* push address instruction: Simple Constraints. (line 164) 48070* PUSH_ARGS: Stack Arguments. (line 18) 48071* PUSH_ARGS_REVERSED: Stack Arguments. (line 26) 48072* push_operand: Machine-Independent Predicates. 48073 (line 81) 48074* push_reload: Addressing Modes. (line 177) 48075* PUSH_ROUNDING: Stack Arguments. (line 32) 48076* pushM1 instruction pattern: Standard Names. (line 256) 48077* PUT_CODE: RTL Objects. (line 47) 48078* PUT_MODE: Machine Modes. (line 283) 48079* PUT_REG_NOTE_KIND: Insns. (line 357) 48080* PUT_SDB_: SDB and DWARF. (line 106) 48081* QCmode: Machine Modes. (line 197) 48082* QFmode: Machine Modes. (line 54) 48083* QImode: Machine Modes. (line 25) 48084* QImode, in insn: Insns. (line 278) 48085* QQmode: Machine Modes. (line 103) 48086* qualified type <1>: Types for C++. (line 6) 48087* qualified type: Types. (line 6) 48088* querying function unit reservations: Processor pipeline description. 48089 (line 90) 48090* question mark: Multi-Alternative. (line 41) 48091* quotient: Arithmetic. (line 116) 48092* r in constraint: Simple Constraints. (line 66) 48093* RDIV_EXPR: Unary and Binary Expressions. 48094 (line 6) 48095* READONLY_DATA_SECTION_ASM_OP: Sections. (line 63) 48096* real operands: SSA Operands. (line 6) 48097* REAL_ARITHMETIC: Floating Point. (line 66) 48098* REAL_CST: Constant expressions. 48099 (line 6) 48100* REAL_LIBGCC_SPEC: Driver. (line 125) 48101* REAL_NM_FILE_NAME: Macros for Initialization. 48102 (line 106) 48103* REAL_TYPE: Types. (line 6) 48104* REAL_VALUE_ABS: Floating Point. (line 82) 48105* REAL_VALUE_ATOF: Floating Point. (line 50) 48106* REAL_VALUE_FIX: Floating Point. (line 41) 48107* REAL_VALUE_FROM_INT: Floating Point. (line 92) 48108* REAL_VALUE_ISINF: Floating Point. (line 59) 48109* REAL_VALUE_ISNAN: Floating Point. (line 62) 48110* REAL_VALUE_NEGATE: Floating Point. (line 79) 48111* REAL_VALUE_NEGATIVE: Floating Point. (line 56) 48112* REAL_VALUE_TO_INT: Floating Point. (line 86) 48113* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 145) 48114* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 143) 48115* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 144) 48116* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 141) 48117* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 142) 48118* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 140) 48119* REAL_VALUE_TYPE: Floating Point. (line 26) 48120* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45) 48121* REAL_VALUES_EQUAL: Floating Point. (line 32) 48122* REAL_VALUES_LESS: Floating Point. (line 38) 48123* REALPART_EXPR: Unary and Binary Expressions. 48124 (line 6) 48125* recog_data.operand: Instruction Output. (line 54) 48126* recognizing insns: RTL Template. (line 6) 48127* RECORD_TYPE <1>: Classes. (line 6) 48128* RECORD_TYPE: Types. (line 6) 48129* redirect_edge_and_branch: Profile information. 48130 (line 71) 48131* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 48132 (line 92) 48133* reduc_smax_M instruction pattern: Standard Names. (line 310) 48134* reduc_smin_M instruction pattern: Standard Names. (line 310) 48135* reduc_splus_M instruction pattern: Standard Names. (line 322) 48136* reduc_umax_M instruction pattern: Standard Names. (line 316) 48137* reduc_umin_M instruction pattern: Standard Names. (line 316) 48138* reduc_uplus_M instruction pattern: Standard Names. (line 328) 48139* reference: Types. (line 6) 48140* REFERENCE_TYPE: Types. (line 6) 48141* reg: Regs and Memory. (line 9) 48142* reg and /f: Flags. (line 94) 48143* reg and /i: Flags. (line 89) 48144* reg and /v: Flags. (line 98) 48145* reg, RTL sharing: Sharing. (line 17) 48146* REG_ALLOC_ORDER: Allocation Order. (line 9) 48147* REG_BR_PRED: Insns. (line 538) 48148* REG_BR_PROB: Insns. (line 532) 48149* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 48150 (line 82) 48151* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 48152 (line 52) 48153* REG_CC_SETTER: Insns. (line 503) 48154* REG_CC_USER: Insns. (line 503) 48155* REG_CLASS_CONTENTS: Register Classes. (line 93) 48156* reg_class_contents: Register Basics. (line 59) 48157* REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35) 48158* REG_CLASS_FROM_LETTER: Old Constraints. (line 27) 48159* REG_CLASS_NAMES: Register Classes. (line 88) 48160* REG_CROSSING_JUMP: Insns. (line 416) 48161* REG_DEAD: Insns. (line 368) 48162* REG_DEAD, REG_UNUSED: Liveness information. 48163 (line 32) 48164* REG_DEP_ANTI: Insns. (line 525) 48165* REG_DEP_OUTPUT: Insns. (line 521) 48166* REG_DEP_TRUE: Insns. (line 518) 48167* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110) 48168* REG_EQUAL: Insns. (line 431) 48169* REG_EQUIV: Insns. (line 431) 48170* REG_EXPR: Special Accessors. (line 60) 48171* REG_FRAME_RELATED_EXPR: Insns. (line 544) 48172* REG_FUNCTION_VALUE_P: Flags. (line 89) 48173* REG_INC: Insns. (line 384) 48174* reg_label and /v: Flags. (line 65) 48175* REG_LABEL_OPERAND: Insns. (line 398) 48176* REG_LABEL_TARGET: Insns. (line 407) 48177* reg_names <1>: Instruction Output. (line 108) 48178* reg_names: Register Basics. (line 59) 48179* REG_NONNEG: Insns. (line 390) 48180* REG_NOTE_KIND: Insns. (line 357) 48181* REG_NOTES: Insns. (line 331) 48182* REG_OFFSET: Special Accessors. (line 64) 48183* REG_OK_STRICT: Addressing Modes. (line 100) 48184* REG_PARM_STACK_SPACE: Stack Arguments. (line 59) 48185* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 48186 (line 51) 48187* REG_POINTER: Flags. (line 94) 48188* REG_SETJMP: Insns. (line 425) 48189* REG_UNUSED: Insns. (line 377) 48190* REG_USERVAR_P: Flags. (line 98) 48191* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 157) 48192* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 36) 48193* regclass_for_constraint: C Constraint Interface. 48194 (line 60) 48195* register allocation order: Allocation Order. (line 6) 48196* register class definitions: Register Classes. (line 6) 48197* register class preference constraints: Class Preferences. (line 6) 48198* register pairs: Values in Registers. 48199 (line 69) 48200* Register Transfer Language (RTL): RTL. (line 6) 48201* register usage: Registers. (line 6) 48202* REGISTER_MOVE_COST: Costs. (line 10) 48203* REGISTER_NAMES: Instruction Output. (line 9) 48204* register_operand: Machine-Independent Predicates. 48205 (line 30) 48206* REGISTER_PREFIX: Instruction Output. (line 152) 48207* REGISTER_TARGET_PRAGMAS: Misc. (line 380) 48208* registers arguments: Register Arguments. (line 6) 48209* registers in constraints: Simple Constraints. (line 66) 48210* REGMODE_NATURAL_SIZE: Values in Registers. 48211 (line 50) 48212* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 176) 48213* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 153) 48214* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 163) 48215* REGNO_OK_FOR_BASE_P: Register Classes. (line 149) 48216* REGNO_OK_FOR_INDEX_P: Register Classes. (line 190) 48217* REGNO_REG_CLASS: Register Classes. (line 108) 48218* regs_ever_live: Function Entry. (line 21) 48219* regular expressions: Processor pipeline description. 48220 (line 6) 48221* relative costs: Costs. (line 6) 48222* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 263) 48223* reload_completed: Standard Names. (line 1187) 48224* reload_in instruction pattern: Standard Names. (line 99) 48225* reload_in_progress: Standard Names. (line 57) 48226* reload_out instruction pattern: Standard Names. (line 99) 48227* reloading: RTL passes. (line 183) 48228* remainder: Arithmetic. (line 136) 48229* remainderM3 instruction pattern: Standard Names. (line 555) 48230* reorder: GTY Options. (line 210) 48231* representation of RTL: RTL. (line 6) 48232* reservation delays: Processor pipeline description. 48233 (line 6) 48234* rest_of_decl_compilation: Parsing pass. (line 52) 48235* rest_of_type_compilation: Parsing pass. (line 52) 48236* restore_stack_block instruction pattern: Standard Names. (line 1322) 48237* restore_stack_function instruction pattern: Standard Names. 48238 (line 1322) 48239* restore_stack_nonlocal instruction pattern: Standard Names. 48240 (line 1322) 48241* RESULT_DECL: Declarations. (line 6) 48242* return: Side Effects. (line 72) 48243* return instruction pattern: Standard Names. (line 1160) 48244* return values in registers: Scalar Return. (line 6) 48245* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135) 48246* RETURN_ADDR_OFFSET: Exception Handling. (line 60) 48247* RETURN_ADDR_RTX: Frame Layout. (line 124) 48248* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 65) 48249* RETURN_EXPR: Statements for C++. (line 6) 48250* RETURN_STMT: Statements for C++. (line 6) 48251* return_val: Flags. (line 274) 48252* return_val, in call_insn: Flags. (line 24) 48253* return_val, in reg: Flags. (line 89) 48254* return_val, in symbol_ref: Flags. (line 202) 48255* returning aggregate values: Aggregate Return. (line 6) 48256* returning structures and unions: Interface. (line 10) 48257* reverse probability: Profile information. 48258 (line 66) 48259* REVERSE_CONDITION: MODE_CC Condition Codes. 48260 (line 94) 48261* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 48262 (line 79) 48263* right rotate: Arithmetic. (line 195) 48264* right shift: Arithmetic. (line 190) 48265* rintM2 instruction pattern: Standard Names. (line 668) 48266* RISC: Processor pipeline description. 48267 (line 6) 48268* roots, marking: GGC Roots. (line 6) 48269* rotate: Arithmetic. (line 195) 48270* rotatert: Arithmetic. (line 195) 48271* rotlM3 instruction pattern: Standard Names. (line 520) 48272* rotrM3 instruction pattern: Standard Names. (line 520) 48273* ROUND_DIV_EXPR: Unary and Binary Expressions. 48274 (line 6) 48275* ROUND_MOD_EXPR: Unary and Binary Expressions. 48276 (line 6) 48277* ROUND_TOWARDS_ZERO: Storage Layout. (line 477) 48278* ROUND_TYPE_ALIGN: Storage Layout. (line 424) 48279* roundM2 instruction pattern: Standard Names. (line 644) 48280* RSHIFT_EXPR: Unary and Binary Expressions. 48281 (line 6) 48282* RTL addition: Arithmetic. (line 14) 48283* RTL addition with signed saturation: Arithmetic. (line 14) 48284* RTL addition with unsigned saturation: Arithmetic. (line 14) 48285* RTL classes: RTL Classes. (line 6) 48286* RTL comparison: Arithmetic. (line 43) 48287* RTL comparison operations: Comparisons. (line 6) 48288* RTL constant expression types: Constants. (line 6) 48289* RTL constants: Constants. (line 6) 48290* RTL declarations: RTL Declarations. (line 6) 48291* RTL difference: Arithmetic. (line 36) 48292* RTL expression: RTL Objects. (line 6) 48293* RTL expressions for arithmetic: Arithmetic. (line 6) 48294* RTL format: RTL Classes. (line 72) 48295* RTL format characters: RTL Classes. (line 77) 48296* RTL function-call insns: Calls. (line 6) 48297* RTL insn template: RTL Template. (line 6) 48298* RTL integers: RTL Objects. (line 6) 48299* RTL memory expressions: Regs and Memory. (line 6) 48300* RTL object types: RTL Objects. (line 6) 48301* RTL postdecrement: Incdec. (line 6) 48302* RTL postincrement: Incdec. (line 6) 48303* RTL predecrement: Incdec. (line 6) 48304* RTL preincrement: Incdec. (line 6) 48305* RTL register expressions: Regs and Memory. (line 6) 48306* RTL representation: RTL. (line 6) 48307* RTL side effect expressions: Side Effects. (line 6) 48308* RTL strings: RTL Objects. (line 6) 48309* RTL structure sharing assumptions: Sharing. (line 6) 48310* RTL subtraction: Arithmetic. (line 36) 48311* RTL subtraction with signed saturation: Arithmetic. (line 36) 48312* RTL subtraction with unsigned saturation: Arithmetic. (line 36) 48313* RTL sum: Arithmetic. (line 14) 48314* RTL vectors: RTL Objects. (line 6) 48315* RTL_CONST_CALL_P: Flags. (line 19) 48316* RTL_CONST_OR_PURE_CALL_P: Flags. (line 29) 48317* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33) 48318* RTL_PURE_CALL_P: Flags. (line 24) 48319* RTX (See RTL): RTL Objects. (line 6) 48320* RTX codes, classes of: RTL Classes. (line 6) 48321* RTX_FRAME_RELATED_P: Flags. (line 107) 48322* run-time conventions: Interface. (line 6) 48323* run-time target specification: Run-time Target. (line 6) 48324* s in constraint: Simple Constraints. (line 102) 48325* same_type_p: Types. (line 88) 48326* SAmode: Machine Modes. (line 148) 48327* sat_fract: Conversions. (line 90) 48328* satfractMN2 instruction pattern: Standard Names. (line 925) 48329* satfractunsMN2 instruction pattern: Standard Names. (line 938) 48330* satisfies_constraint_: C Constraint Interface. 48331 (line 47) 48332* SAVE_EXPR: Unary and Binary Expressions. 48333 (line 6) 48334* save_stack_block instruction pattern: Standard Names. (line 1322) 48335* save_stack_function instruction pattern: Standard Names. (line 1322) 48336* save_stack_nonlocal instruction pattern: Standard Names. (line 1322) 48337* SBSS_SECTION_ASM_OP: Sections. (line 76) 48338* Scalar evolutions: Scalar evolutions. (line 6) 48339* scalars, returned as values: Scalar Return. (line 6) 48340* SCHED_GROUP_P: Flags. (line 148) 48341* SCmode: Machine Modes. (line 197) 48342* scratch: Regs and Memory. (line 298) 48343* scratch operands: Regs and Memory. (line 298) 48344* scratch, RTL sharing: Sharing. (line 35) 48345* scratch_operand: Machine-Independent Predicates. 48346 (line 50) 48347* SDATA_SECTION_ASM_OP: Sections. (line 58) 48348* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 124) 48349* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 119) 48350* SDB_DEBUGGING_INFO: SDB and DWARF. (line 9) 48351* SDB_DELIM: SDB and DWARF. (line 112) 48352* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 129) 48353* SDmode: Machine Modes. (line 85) 48354* sdot_prodM instruction pattern: Standard Names. (line 334) 48355* search options: Including Patterns. (line 44) 48356* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 396) 48357* SECONDARY_MEMORY_NEEDED: Register Classes. (line 452) 48358* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 471) 48359* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 462) 48360* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 397) 48361* SECONDARY_RELOAD_CLASS: Register Classes. (line 395) 48362* SELECT_CC_MODE: MODE_CC Condition Codes. 48363 (line 7) 48364* sequence: Side Effects. (line 260) 48365* Sequence iterators: Sequence iterators. (line 6) 48366* set: Side Effects. (line 15) 48367* set and /f: Flags. (line 107) 48368* SET_ASM_OP: Label Output. (line 419) 48369* set_attr: Tagging Insns. (line 31) 48370* set_attr_alternative: Tagging Insns. (line 49) 48371* set_bb_seq: GIMPLE sequences. (line 76) 48372* SET_BY_PIECES_P: Costs. (line 206) 48373* SET_DEST: Side Effects. (line 69) 48374* SET_IS_RETURN_P: Flags. (line 157) 48375* SET_LABEL_KIND: Insns. (line 146) 48376* set_optab_libfunc: Library Calls. (line 15) 48377* SET_RATIO: Costs. (line 194) 48378* SET_SRC: Side Effects. (line 69) 48379* set_thread_pointerMODE instruction pattern: Standard Names. 48380 (line 1856) 48381* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 48382* setmemM instruction pattern: Standard Names. (line 793) 48383* SETUP_FRAME_ADDRESSES: Frame Layout. (line 102) 48384* SF_SIZE: Type Layout. (line 136) 48385* SFmode: Machine Modes. (line 66) 48386* sharing of RTL components: Sharing. (line 6) 48387* shift: Arithmetic. (line 173) 48388* SHIFT_COUNT_TRUNCATED: Misc. (line 113) 48389* SHLIB_SUFFIX: Macros for Initialization. 48390 (line 135) 48391* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83) 48392* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63) 48393* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 87) 48394* SHORT_TYPE_SIZE: Type Layout. (line 16) 48395* sibcall_epilogue instruction pattern: Standard Names. (line 1532) 48396* sibling call: Edges. (line 122) 48397* SIBLING_CALL_P: Flags. (line 161) 48398* SIG_ATOMIC_TYPE: Type Layout. (line 252) 48399* sign_extend: Conversions. (line 23) 48400* sign_extract: Bit-Fields. (line 8) 48401* sign_extract, canonicalization of: Insn Canonicalizations. 48402 (line 88) 48403* signed division: Arithmetic. (line 116) 48404* signed division with signed saturation: Arithmetic. (line 116) 48405* signed maximum: Arithmetic. (line 141) 48406* signed minimum: Arithmetic. (line 141) 48407* SImode: Machine Modes. (line 37) 48408* simple constraints: Simple Constraints. (line 6) 48409* simple_return: Side Effects. (line 86) 48410* simple_return instruction pattern: Standard Names. (line 1176) 48411* sincos math function, implicit usage: Library Calls. (line 78) 48412* sincosM3 instruction pattern: Standard Names. (line 580) 48413* sinM2 instruction pattern: Standard Names. (line 572) 48414* SIZE_ASM_OP: Label Output. (line 35) 48415* SIZE_TYPE: Type Layout. (line 175) 48416* SIZETYPE: Type Layout. (line 191) 48417* skip: GTY Options. (line 77) 48418* SLOW_BYTE_ACCESS: Costs. (line 118) 48419* SLOW_UNALIGNED_ACCESS: Costs. (line 133) 48420* smax: Arithmetic. (line 141) 48421* smin: Arithmetic. (line 141) 48422* sms, swing, software pipelining: RTL passes. (line 132) 48423* smulM3_highpart instruction pattern: Standard Names. (line 435) 48424* soft float library: Soft float library routines. 48425 (line 6) 48426* special: GTY Options. (line 295) 48427* special predicates: Predicates. (line 31) 48428* SPECS: Target Fragment. (line 191) 48429* speed of instructions: Costs. (line 6) 48430* split_block: Maintaining the CFG. 48431 (line 99) 48432* splitting instructions: Insn Splitting. (line 6) 48433* SQmode: Machine Modes. (line 111) 48434* sqrt: Arithmetic. (line 207) 48435* sqrtM2 instruction pattern: Standard Names. (line 538) 48436* square root: Arithmetic. (line 207) 48437* ss_abs: Arithmetic. (line 200) 48438* ss_ashift: Arithmetic. (line 173) 48439* ss_div: Arithmetic. (line 116) 48440* ss_minus: Arithmetic. (line 36) 48441* ss_mult: Arithmetic. (line 92) 48442* ss_neg: Arithmetic. (line 81) 48443* ss_plus: Arithmetic. (line 14) 48444* ss_truncate: Conversions. (line 43) 48445* SSA: SSA. (line 6) 48446* SSA_NAME_DEF_STMT: SSA. (line 219) 48447* SSA_NAME_VERSION: SSA. (line 224) 48448* ssaddM3 instruction pattern: Standard Names. (line 269) 48449* ssashlM3 instruction pattern: Standard Names. (line 510) 48450* ssdivM3 instruction pattern: Standard Names. (line 269) 48451* ssmaddMN4 instruction pattern: Standard Names. (line 458) 48452* ssmsubMN4 instruction pattern: Standard Names. (line 482) 48453* ssmulM3 instruction pattern: Standard Names. (line 269) 48454* ssnegM2 instruction pattern: Standard Names. (line 532) 48455* sssubM3 instruction pattern: Standard Names. (line 269) 48456* ssum_widenM3 instruction pattern: Standard Names. (line 344) 48457* stack arguments: Stack Arguments. (line 6) 48458* stack frame layout: Frame Layout. (line 6) 48459* stack smashing protection: Stack Smashing Protection. 48460 (line 6) 48461* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48) 48462* STACK_BOUNDARY: Storage Layout. (line 146) 48463* STACK_CHECK_BUILTIN: Stack Checking. (line 32) 48464* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 48465* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 48466* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 48467* STACK_CHECK_MOVING_SP: Stack Checking. (line 54) 48468* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 46) 48469* STACK_CHECK_PROTECT: Stack Checking. (line 63) 48470* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39) 48471* STACK_DYNAMIC_OFFSET: Frame Layout. (line 75) 48472* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 48473 (line 83) 48474* STACK_GROWS_DOWNWARD: Frame Layout. (line 9) 48475* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 90) 48476* STACK_POINTER_OFFSET: Frame Layout. (line 58) 48477* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 48478 (line 93) 48479* STACK_POINTER_REGNUM: Frame Registers. (line 9) 48480* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 48481 (line 83) 48482* stack_pointer_rtx: Frame Registers. (line 104) 48483* stack_protect_set instruction pattern: Standard Names. (line 1866) 48484* stack_protect_test instruction pattern: Standard Names. (line 1876) 48485* STACK_PUSH_CODE: Frame Layout. (line 17) 48486* STACK_REG_COVER_CLASS: Stack Registers. (line 23) 48487* STACK_REGS: Stack Registers. (line 20) 48488* STACK_SAVEAREA_MODE: Storage Layout. (line 440) 48489* STACK_SIZE_MODE: Storage Layout. (line 452) 48490* STACK_SLOT_ALIGNMENT: Storage Layout. (line 271) 48491* standard pattern names: Standard Names. (line 6) 48492* STANDARD_STARTFILE_PREFIX: Driver. (line 275) 48493* STANDARD_STARTFILE_PREFIX_1: Driver. (line 282) 48494* STANDARD_STARTFILE_PREFIX_2: Driver. (line 289) 48495* STARTFILE_SPEC: Driver. (line 148) 48496* STARTING_FRAME_OFFSET: Frame Layout. (line 39) 48497* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 48498 (line 74) 48499* Statement and operand traversals: Statement and operand traversals. 48500 (line 6) 48501* Statement Sequences: Statement Sequences. 48502 (line 6) 48503* statements <1>: Statements for C++. (line 6) 48504* statements: Function Properties. 48505 (line 6) 48506* Statements: Statements. (line 6) 48507* Static profile estimation: Profile information. 48508 (line 24) 48509* static single assignment: SSA. (line 6) 48510* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 78) 48511* STATIC_CHAIN_REGNUM: Frame Registers. (line 77) 48512* stdarg.h and register arguments: Register Arguments. (line 45) 48513* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 351) 48514* STMT_EXPR: Unary and Binary Expressions. 48515 (line 6) 48516* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 48517* storage layout: Storage Layout. (line 6) 48518* STORE_BY_PIECES_P: Costs. (line 213) 48519* STORE_FLAG_VALUE: Misc. (line 202) 48520* store_multiple instruction pattern: Standard Names. (line 160) 48521* strcpy: Storage Layout. (line 231) 48522* STRICT_ALIGNMENT: Storage Layout. (line 321) 48523* strict_low_part: RTL Declarations. (line 9) 48524* strict_memory_address_p: Addressing Modes. (line 187) 48525* STRING_CST: Constant expressions. 48526 (line 6) 48527* STRING_POOL_ADDRESS_P: Flags. (line 165) 48528* strlenM instruction pattern: Standard Names. (line 860) 48529* structure value address: Aggregate Return. (line 6) 48530* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 313) 48531* structures, returning: Interface. (line 10) 48532* subM3 instruction pattern: Standard Names. (line 269) 48533* SUBOBJECT: Statements for C++. (line 6) 48534* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 48535* subreg: Regs and Memory. (line 97) 48536* subreg and /s: Flags. (line 187) 48537* subreg and /u: Flags. (line 180) 48538* subreg and /u and /v: Flags. (line 170) 48539* subreg, in strict_low_part: RTL Declarations. (line 9) 48540* SUBREG_BYTE: Regs and Memory. (line 289) 48541* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 170) 48542* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 180) 48543* SUBREG_PROMOTED_VAR_P: Flags. (line 187) 48544* SUBREG_REG: Regs and Memory. (line 289) 48545* subst iterators in .md files: Subst Iterators. (line 6) 48546* SUCCESS_EXIT_CODE: Host Misc. (line 12) 48547* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 48548 (line 58) 48549* SUPPORTS_ONE_ONLY: Label Output. (line 259) 48550* SUPPORTS_WEAK: Label Output. (line 233) 48551* SWITCH_BODY: Statements for C++. (line 6) 48552* SWITCH_COND: Statements for C++. (line 6) 48553* SWITCH_STMT: Statements for C++. (line 6) 48554* SWITCHABLE_TARGET: Run-time Target. (line 165) 48555* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 120) 48556* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 102) 48557* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 95) 48558* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 116) 48559* SYMBOL_FLAG_LOCAL: Special Accessors. (line 98) 48560* SYMBOL_FLAG_SMALL: Special Accessors. (line 107) 48561* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 111) 48562* symbol_ref: Constants. (line 87) 48563* symbol_ref and /f: Flags. (line 165) 48564* symbol_ref and /i: Flags. (line 202) 48565* symbol_ref and /u: Flags. (line 10) 48566* symbol_ref and /v: Flags. (line 206) 48567* symbol_ref, RTL sharing: Sharing. (line 20) 48568* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 120) 48569* SYMBOL_REF_BLOCK: Special Accessors. (line 133) 48570* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 138) 48571* SYMBOL_REF_CONSTANT: Special Accessors. (line 81) 48572* SYMBOL_REF_DATA: Special Accessors. (line 85) 48573* SYMBOL_REF_DECL: Special Accessors. (line 69) 48574* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 102) 48575* SYMBOL_REF_FLAG: Flags. (line 206) 48576* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 277) 48577* SYMBOL_REF_FLAGS: Special Accessors. (line 89) 48578* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 95) 48579* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 116) 48580* SYMBOL_REF_LOCAL_P: Special Accessors. (line 98) 48581* SYMBOL_REF_SMALL_P: Special Accessors. (line 107) 48582* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 111) 48583* SYMBOL_REF_USED: Flags. (line 197) 48584* SYMBOL_REF_WEAK: Flags. (line 202) 48585* symbolic label: Sharing. (line 20) 48586* sync_addMODE instruction pattern: Standard Names. (line 1631) 48587* sync_andMODE instruction pattern: Standard Names. (line 1631) 48588* sync_compare_and_swapMODE instruction pattern: Standard Names. 48589 (line 1591) 48590* sync_iorMODE instruction pattern: Standard Names. (line 1631) 48591* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1696) 48592* sync_lock_test_and_setMODE instruction pattern: Standard Names. 48593 (line 1670) 48594* sync_nandMODE instruction pattern: Standard Names. (line 1631) 48595* sync_new_addMODE instruction pattern: Standard Names. (line 1663) 48596* sync_new_andMODE instruction pattern: Standard Names. (line 1663) 48597* sync_new_iorMODE instruction pattern: Standard Names. (line 1663) 48598* sync_new_nandMODE instruction pattern: Standard Names. (line 1663) 48599* sync_new_subMODE instruction pattern: Standard Names. (line 1663) 48600* sync_new_xorMODE instruction pattern: Standard Names. (line 1663) 48601* sync_old_addMODE instruction pattern: Standard Names. (line 1646) 48602* sync_old_andMODE instruction pattern: Standard Names. (line 1646) 48603* sync_old_iorMODE instruction pattern: Standard Names. (line 1646) 48604* sync_old_nandMODE instruction pattern: Standard Names. (line 1646) 48605* sync_old_subMODE instruction pattern: Standard Names. (line 1646) 48606* sync_old_xorMODE instruction pattern: Standard Names. (line 1646) 48607* sync_subMODE instruction pattern: Standard Names. (line 1631) 48608* sync_xorMODE instruction pattern: Standard Names. (line 1631) 48609* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 177) 48610* SYSROOT_SUFFIX_SPEC: Driver. (line 172) 48611* t-TARGET: Target Fragment. (line 6) 48612* table jump: Basic Blocks. (line 67) 48613* tablejump instruction pattern: Standard Names. (line 1249) 48614* tag: GTY Options. (line 82) 48615* tagging insns: Tagging Insns. (line 6) 48616* tail calls: Tail Calls. (line 6) 48617* TAmode: Machine Modes. (line 156) 48618* target attributes: Target Attributes. (line 6) 48619* target description macros: Target Macros. (line 6) 48620* target functions: Target Structure. (line 6) 48621* target hooks: Target Structure. (line 6) 48622* target makefile fragment: Target Fragment. (line 6) 48623* target specifications: Run-time Target. (line 6) 48624* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 48625 (line 45) 48626* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 48627 (line 88) 48628* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 48629 (line 63) 48630* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 48631 (line 72) 48632* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 48633 (line 38) 48634* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 48635 (line 79) 48636* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 48637 (line 52) 48638* TARGET_ADDRESS_COST: Costs. (line 302) 48639* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 398) 48640* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 700) 48641* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 980) 48642* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 247) 48643* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 84) 48644* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 48645 (line 129) 48646* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 337) 48647* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1008) 48648* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10) 48649* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8) 48650* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 48651* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11) 48652* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 271) 48653* TARGET_ASM_BYTE_OP: Data Output. (line 7) 48654* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 207) 48655* TARGET_ASM_CLOSE_PAREN: Data Output. (line 131) 48656* TARGET_ASM_CODE_END: File Framework. (line 59) 48657* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 48658 (line 69) 48659* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 154) 48660* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 48661 (line 83) 48662* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 82) 48663* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74) 48664* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63) 48665* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 306) 48666* TARGET_ASM_FILE_END: File Framework. (line 37) 48667* TARGET_ASM_FILE_START: File Framework. (line 9) 48668* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17) 48669* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31) 48670* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 84) 48671* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61) 48672* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55) 48673* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68) 48674* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11) 48675* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 215) 48676* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 124) 48677* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 48678 (line 134) 48679* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 199) 48680* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 190) 48681* TARGET_ASM_INIT_SECTIONS: Sections. (line 160) 48682* TARGET_ASM_INTEGER: Data Output. (line 27) 48683* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 350) 48684* TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 22) 48685* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 48686 (line 36) 48687* TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 69) 48688* TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 54) 48689* TARGET_ASM_LTO_END: File Framework. (line 54) 48690* TARGET_ASM_LTO_START: File Framework. (line 49) 48691* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 313) 48692* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 222) 48693* TARGET_ASM_NAMED_SECTION: File Framework. (line 116) 48694* TARGET_ASM_OPEN_PAREN: Data Output. (line 130) 48695* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 40) 48696* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44) 48697* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 101) 48698* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 102) 48699* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 165) 48700* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 94) 48701* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 165) 48702* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 209) 48703* TARGET_ASM_RELOC_RW_MASK: Sections. (line 169) 48704* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 232) 48705* TARGET_ASM_SELECT_SECTION: Sections. (line 181) 48706* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 227) 48707* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 29) 48708* TARGET_ASM_TTYPE: Exception Region Output. 48709 (line 123) 48710* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14) 48711* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12) 48712* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13) 48713* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15) 48714* TARGET_ASM_UNIQUE_SECTION: Sections. (line 202) 48715* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 88) 48716* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93) 48717* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1018) 48718* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11) 48719* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 19) 48720* TARGET_BINDS_LOCAL_P: Sections. (line 309) 48721* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 797) 48722* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 789) 48723* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 273) 48724* TARGET_BUILTIN_DECL: Misc. (line 597) 48725* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 264) 48726* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109) 48727* TARGET_C99_FUNCTIONS: Library Calls. (line 71) 48728* TARGET_C_PREINCLUDE: Misc. (line 362) 48729* TARGET_CALLEE_COPIES: Register Arguments. (line 116) 48730* TARGET_CAN_ELIMINATE: Elimination. (line 75) 48731* TARGET_CAN_FOLLOW_JUMP: Misc. (line 687) 48732* TARGET_CAN_INLINE_P: Target Attributes. (line 158) 48733* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 237) 48734* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 776) 48735* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 294) 48736* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 48737 (line 58) 48738* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 47) 48739* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 48740 (line 123) 48741* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 28) 48742* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 121) 48743* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 494) 48744* TARGET_CLASS_MAX_NREGS: Register Classes. (line 511) 48745* TARGET_COMMUTATIVE_P: Misc. (line 693) 48746* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 27) 48747* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 637) 48748* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60) 48749* TARGET_CONST_ANCHOR: Misc. (line 991) 48750* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 232) 48751* TARGET_CONVERT_TO_TYPE: Misc. (line 944) 48752* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9) 48753* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87) 48754* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38) 48755* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62) 48756* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25) 48757* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 93) 48758* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54) 48759* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18) 48760* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12) 48761* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7) 48762* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30) 48763* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43) 48764* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69) 48765* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74) 48766* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80) 48767* TARGET_DEBUG_UNWIND_INFO: SDB and DWARF. (line 37) 48768* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 524) 48769* TARGET_DECLSPEC: Target Attributes. (line 73) 48770* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 440) 48771* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 167) 48772* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 56) 48773* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 434) 48774* TARGET_DELAY_SCHED2: SDB and DWARF. (line 66) 48775* TARGET_DELAY_VARTRACK: SDB and DWARF. (line 70) 48776* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 223) 48777* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 570) 48778* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 48779* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18) 48780* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 172) 48781* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 48782 (line 106) 48783* TARGET_EDOM: Library Calls. (line 53) 48784* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68) 48785* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19) 48786* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24) 48787* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45) 48788* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36) 48789* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63) 48790* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49) 48791* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57) 48792* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41) 48793* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31) 48794* TARGET_ENCODE_SECTION_INFO: Sections. (line 253) 48795* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 48796 (line 83) 48797* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 128) 48798* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 278) 48799* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 48800 (line 48) 48801* TARGET_EXECUTABLE_SUFFIX: Misc. (line 750) 48802* TARGET_EXPAND_BUILTIN: Misc. (line 607) 48803* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 67) 48804* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 530) 48805* TARGET_EXPR: Unary and Binary Expressions. 48806 (line 6) 48807* TARGET_EXTRA_INCLUDES: Misc. (line 837) 48808* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21) 48809* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 844) 48810* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 48811 (line 108) 48812* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 527) 48813* target_flags: Run-time Target. (line 52) 48814* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 48815 (line 135) 48816* TARGET_FLT_EVAL_METHOD: Type Layout. (line 148) 48817* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 289) 48818* TARGET_FOLD_BUILTIN: Misc. (line 628) 48819* TARGET_FORCE_AT_COMP_DIR: SDB and DWARF. (line 61) 48820* TARGET_FORMAT_TYPES: Misc. (line 864) 48821* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 9) 48822* TARGET_FUNCTION_ARG: Register Arguments. (line 12) 48823* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 187) 48824* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 241) 48825* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 247) 48826* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 95) 48827* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 68) 48828* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8) 48829* TARGET_FUNCTION_VALUE: Scalar Return. (line 11) 48830* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 97) 48831* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 654) 48832* TARGET_GET_DRAP_RTX: Misc. (line 974) 48833* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 647) 48834* TARGET_GET_PCH_VALIDITY: PCH Target. (line 7) 48835* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 83) 48836* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 78) 48837* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 300) 48838* TARGET_HANDLE_C_OPTION: Run-time Target. (line 75) 48839* TARGET_HANDLE_OPTION: Run-time Target. (line 62) 48840* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 48841 (line 144) 48842* TARGET_HAS_SINCOS: Library Calls. (line 79) 48843* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 811) 48844* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 48845 (line 64) 48846* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 141) 48847* TARGET_HAVE_SRODATA_SECTION: Sections. (line 298) 48848* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 146) 48849* TARGET_HAVE_TLS: Sections. (line 318) 48850* TARGET_IN_SMALL_DATA_P: Sections. (line 294) 48851* TARGET_INIT_BUILTINS: Misc. (line 580) 48852* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 48853 (line 115) 48854* TARGET_INIT_LIBFUNCS: Library Calls. (line 16) 48855* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 82) 48856* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 538) 48857* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 898) 48858* TARGET_INVALID_BINARY_OP: Misc. (line 917) 48859* TARGET_INVALID_CONVERSION: Misc. (line 904) 48860* TARGET_INVALID_PARAMETER_TYPE: Misc. (line 923) 48861* TARGET_INVALID_RETURN_TYPE: Misc. (line 930) 48862* TARGET_INVALID_UNARY_OP: Misc. (line 910) 48863* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 661) 48864* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 50) 48865* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 673) 48866* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 216) 48867* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 132) 48868* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 43) 48869* TARGET_LIBCALL_VALUE: Scalar Return. (line 66) 48870* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 25) 48871* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 461) 48872* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 132) 48873* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 467) 48874* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 818) 48875* TARGET_LRA_P: Register Classes. (line 553) 48876* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 565) 48877* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 325) 48878* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 243) 48879* TARGET_MANGLE_TYPE: Storage Layout. (line 542) 48880* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 39) 48881* TARGET_MD_ASM_CLOBBERS: Misc. (line 486) 48882* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 109) 48883* TARGET_MEM_REF: Storage References. (line 6) 48884* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 413) 48885* TARGET_MEMMODEL_CHECK: Misc. (line 1014) 48886* TARGET_MEMORY_MOVE_COST: Costs. (line 81) 48887* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 47) 48888* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 39) 48889* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 33) 48890* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 92) 48891* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 199) 48892* TARGET_MODE_REP_EXTENDED: Misc. (line 177) 48893* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 497) 48894* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 61) 48895* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 48896 (line 51) 48897* TARGET_N_FORMAT_TYPES: Misc. (line 869) 48898* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 404) 48899* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 90) 48900* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 111) 48901* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 48902 (line 106) 48903* TARGET_OBJECT_SUFFIX: Misc. (line 745) 48904* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46) 48905* TARGET_OPTF: Misc. (line 851) 48906* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 161) 48907* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 151) 48908* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 158) 48909* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 144) 48910* TARGET_OPTION_OVERRIDE: Target Attributes. (line 137) 48911* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 131) 48912* TARGET_OPTION_PRINT: Target Attributes. (line 125) 48913* TARGET_OPTION_RESTORE: Target Attributes. (line 119) 48914* TARGET_OPTION_SAVE: Target Attributes. (line 113) 48915* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 102) 48916* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42) 48917* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 127) 48918* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 873) 48919* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 879) 48920* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 883) 48921* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 104) 48922* TARGET_PCH_VALID_P: PCH Target. (line 13) 48923* TARGET_POSIX_IO: Misc. (line 510) 48924* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 289) 48925* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 218) 48926* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 206) 48927* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 35) 48928* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 128) 48929* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 302) 48930* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 118) 48931* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11) 48932* TARGET_PROMOTED_TYPE: Misc. (line 936) 48933* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 295) 48934* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 311) 48935* TARGET_REGISTER_MOVE_COST: Costs. (line 33) 48936* TARGET_REGISTER_PRIORITY: Register Classes. (line 558) 48937* TARGET_RELAXED_ORDERING: Misc. (line 888) 48938* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 617) 48939* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 17) 48940* TARGET_RETURN_IN_MSB: Scalar Return. (line 117) 48941* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 100) 48942* TARGET_RTX_COSTS: Costs. (line 271) 48943* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 319) 48944* TARGET_SCHED_ADJUST_COST: Scheduling. (line 37) 48945* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52) 48946* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 274) 48947* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 289) 48948* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89) 48949* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 235) 48950* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 160) 48951* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144) 48952* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 153) 48953* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132) 48954* TARGET_SCHED_DISPATCH: Scheduling. (line 355) 48955* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 360) 48956* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 364) 48957* TARGET_SCHED_FINISH: Scheduling. (line 109) 48958* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126) 48959* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 215) 48960* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 204) 48961* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 48962 (line 168) 48963* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 48964 (line 196) 48965* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling. 48966 (line 328) 48967* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 220) 48968* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 230) 48969* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 225) 48970* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 210) 48971* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 293) 48972* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 315) 48973* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 269) 48974* TARGET_SCHED_INIT: Scheduling. (line 99) 48975* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149) 48976* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141) 48977* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118) 48978* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 279) 48979* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 246) 48980* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12) 48981* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 308) 48982* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 370) 48983* TARGET_SCHED_REORDER: Scheduling. (line 60) 48984* TARGET_SCHED_REORDER2: Scheduling. (line 77) 48985* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 285) 48986* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 340) 48987* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 346) 48988* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 297) 48989* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24) 48990* TARGET_SECONDARY_RELOAD: Register Classes. (line 318) 48991* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 152) 48992* TARGET_SET_CURRENT_FUNCTION: Misc. (line 727) 48993* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 34) 48994* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 31) 48995* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 76) 48996* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 140) 48997* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 48998 (line 361) 48999* TARGET_SPILL_CLASS: Register Classes. (line 578) 49000* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 261) 49001* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 49002 (line 17) 49003* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 49004 (line 7) 49005* TARGET_STATIC_CHAIN: Frame Registers. (line 92) 49006* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 112) 49007* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 116) 49008* TARGET_STRIP_NAME_ENCODING: Sections. (line 290) 49009* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 45) 49010* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 49011 (line 27) 49012* TARGET_SUPPORTS_WEAK: Label Output. (line 241) 49013* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 49014 (line 100) 49015* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 75) 49016* TARGET_TRAMPOLINE_INIT: Trampolines. (line 56) 49017* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 719) 49018* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 49019 (line 74) 49020* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 473) 49021* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 970) 49022* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55) 49023* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 251) 49024* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 257) 49025* TARGET_USE_JCR_SECTION: Misc. (line 952) 49026* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 126) 49027* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 68) 49028* TARGET_VALID_POINTER_MODE: Register Arguments. (line 306) 49029* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 264) 49030* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 331) 49031* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 373) 49032* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 49033 (line 353) 49034* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 315) 49035* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 404) 49036* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 273) 49037* TARGET_VECTORIZE_BUILTIN_TM_LOAD: Addressing Modes. (line 395) 49038* TARGET_VECTORIZE_BUILTIN_TM_STORE: Addressing Modes. (line 399) 49039* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 49040 (line 300) 49041* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 49042 (line 327) 49043* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 390) 49044* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 384) 49045* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 361) 49046* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 346) 49047* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 49048 (line 337) 49049* TARGET_VECTORIZE_VEC_PERM_CONST_OK: Addressing Modes. (line 311) 49050* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 49051 (line 306) 49052* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 348) 49053* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 342) 49054* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 331) 49055* TARGET_WANT_DEBUG_PUB_SECTIONS: SDB and DWARF. (line 56) 49056* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 36) 49057* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 277) 49058* targetm: Target Structure. (line 7) 49059* targets, makefile: Makefile. (line 6) 49060* TCmode: Machine Modes. (line 197) 49061* TDmode: Machine Modes. (line 94) 49062* TEMPLATE_DECL: Declarations. (line 6) 49063* Temporaries: Temporaries. (line 6) 49064* termination routines: Initialization. (line 6) 49065* testing constraints: C Constraint Interface. 49066 (line 6) 49067* TEXT_SECTION_ASM_OP: Sections. (line 38) 49068* TF_SIZE: Type Layout. (line 139) 49069* TFmode: Machine Modes. (line 98) 49070* THEN_CLAUSE: Statements for C++. (line 6) 49071* THREAD_MODEL_SPEC: Driver. (line 163) 49072* THROW_EXPR: Unary and Binary Expressions. 49073 (line 6) 49074* THUNK_DECL: Declarations. (line 6) 49075* THUNK_DELTA: Declarations. (line 6) 49076* TImode: Machine Modes. (line 48) 49077* TImode, in insn: Insns. (line 278) 49078* TLS_COMMON_ASM_OP: Sections. (line 81) 49079* TLS_SECTION_ASM_FLAG: Sections. (line 86) 49080* tm.h macros: Target Macros. (line 6) 49081* TQFmode: Machine Modes. (line 62) 49082* TQmode: Machine Modes. (line 119) 49083* TRAMPOLINE_ALIGNMENT: Trampolines. (line 49) 49084* TRAMPOLINE_SECTION: Trampolines. (line 40) 49085* TRAMPOLINE_SIZE: Trampolines. (line 45) 49086* trampolines for nested functions: Trampolines. (line 6) 49087* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 111) 49088* trap instruction pattern: Standard Names. (line 1542) 49089* tree <1>: Macros and Functions. 49090 (line 6) 49091* tree: Tree overview. (line 6) 49092* Tree SSA: Tree SSA. (line 6) 49093* TREE_CHAIN: Macros and Functions. 49094 (line 6) 49095* TREE_CODE: Tree overview. (line 6) 49096* tree_int_cst_equal: Constant expressions. 49097 (line 6) 49098* TREE_INT_CST_HIGH: Constant expressions. 49099 (line 6) 49100* TREE_INT_CST_LOW: Constant expressions. 49101 (line 6) 49102* tree_int_cst_lt: Constant expressions. 49103 (line 6) 49104* TREE_LIST: Containers. (line 6) 49105* TREE_OPERAND: Expression trees. (line 6) 49106* TREE_PUBLIC <1>: Function Properties. 49107 (line 28) 49108* TREE_PUBLIC: Function Basics. (line 6) 49109* TREE_PURPOSE: Containers. (line 6) 49110* TREE_READONLY: Function Properties. 49111 (line 37) 49112* tree_size: Macros and Functions. 49113 (line 13) 49114* TREE_STATIC: Function Properties. 49115 (line 31) 49116* TREE_STRING_LENGTH: Constant expressions. 49117 (line 6) 49118* TREE_STRING_POINTER: Constant expressions. 49119 (line 6) 49120* TREE_THIS_VOLATILE: Function Properties. 49121 (line 34) 49122* TREE_TYPE <1>: Types for C++. (line 6) 49123* TREE_TYPE <2>: Function Basics. (line 47) 49124* TREE_TYPE <3>: Expression trees. (line 6) 49125* TREE_TYPE <4>: Working with declarations. 49126 (line 11) 49127* TREE_TYPE <5>: Types. (line 6) 49128* TREE_TYPE: Macros and Functions. 49129 (line 6) 49130* TREE_VALUE: Containers. (line 6) 49131* TREE_VEC: Containers. (line 6) 49132* TREE_VEC_ELT: Containers. (line 6) 49133* TREE_VEC_LENGTH: Containers. (line 6) 49134* TRULY_NOOP_TRUNCATION: Misc. (line 163) 49135* TRUNC_DIV_EXPR: Unary and Binary Expressions. 49136 (line 6) 49137* TRUNC_MOD_EXPR: Unary and Binary Expressions. 49138 (line 6) 49139* truncate: Conversions. (line 38) 49140* truncMN2 instruction pattern: Standard Names. (line 903) 49141* TRUTH_AND_EXPR: Unary and Binary Expressions. 49142 (line 6) 49143* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 49144 (line 6) 49145* TRUTH_NOT_EXPR: Unary and Binary Expressions. 49146 (line 6) 49147* TRUTH_OR_EXPR: Unary and Binary Expressions. 49148 (line 6) 49149* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 49150 (line 6) 49151* TRUTH_XOR_EXPR: Unary and Binary Expressions. 49152 (line 6) 49153* TRY_BLOCK: Statements for C++. (line 6) 49154* TRY_HANDLERS: Statements for C++. (line 6) 49155* TRY_STMTS: Statements for C++. (line 6) 49156* Tuple specific accessors: Tuple specific accessors. 49157 (line 6) 49158* tuples: Tuple representation. 49159 (line 6) 49160* type: Types. (line 6) 49161* type declaration: Declarations. (line 6) 49162* TYPE_ALIGN <1>: Types for C++. (line 6) 49163* TYPE_ALIGN: Types. (line 6) 49164* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 49165* TYPE_ARG_TYPES: Types. (line 6) 49166* TYPE_ASM_OP: Label Output. (line 79) 49167* TYPE_ATTRIBUTES: Attributes. (line 25) 49168* TYPE_BINFO: Classes. (line 6) 49169* TYPE_BUILT_IN: Types for C++. (line 68) 49170* TYPE_CANONICAL: Types. (line 6) 49171* TYPE_CONTEXT <1>: Types for C++. (line 6) 49172* TYPE_CONTEXT: Types. (line 6) 49173* TYPE_DECL: Declarations. (line 6) 49174* TYPE_FIELDS <1>: Classes. (line 6) 49175* TYPE_FIELDS <2>: Types for C++. (line 6) 49176* TYPE_FIELDS: Types. (line 6) 49177* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96) 49178* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81) 49179* TYPE_HAS_MUTABLE_P: Classes. (line 86) 49180* TYPE_HAS_NEW_OPERATOR: Classes. (line 93) 49181* TYPE_MAIN_VARIANT <1>: Types for C++. (line 6) 49182* TYPE_MAIN_VARIANT: Types. (line 6) 49183* TYPE_MAX_VALUE: Types. (line 6) 49184* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 49185* TYPE_METHOD_BASETYPE: Types. (line 6) 49186* TYPE_METHODS: Classes. (line 6) 49187* TYPE_MIN_VALUE: Types. (line 6) 49188* TYPE_NAME <1>: Types for C++. (line 6) 49189* TYPE_NAME: Types. (line 6) 49190* TYPE_NOTHROW_P: Functions for C++. (line 154) 49191* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 49192* TYPE_OFFSET_BASETYPE: Types. (line 6) 49193* TYPE_OPERAND_FMT: Label Output. (line 90) 49194* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104) 49195* TYPE_OVERLOADS_ARROW: Classes. (line 107) 49196* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100) 49197* TYPE_POLYMORPHIC_P: Classes. (line 77) 49198* TYPE_PRECISION <1>: Types for C++. (line 6) 49199* TYPE_PRECISION: Types. (line 6) 49200* TYPE_PTR_P: Types for C++. (line 74) 49201* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 49202* TYPE_PTRFN_P: Types for C++. (line 78) 49203* TYPE_PTROB_P: Types for C++. (line 81) 49204* TYPE_PTROBV_P: Types for C++. (line 6) 49205* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 49206* TYPE_QUAL_CONST: Types. (line 6) 49207* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 49208* TYPE_QUAL_RESTRICT: Types. (line 6) 49209* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 49210* TYPE_QUAL_VOLATILE: Types. (line 6) 49211* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 49212* TYPE_SIZE <1>: Types for C++. (line 6) 49213* TYPE_SIZE: Types. (line 6) 49214* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 49215* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 49216* TYPE_UNQUALIFIED: Types. (line 6) 49217* TYPE_VFIELD: Classes. (line 6) 49218* TYPENAME_TYPE: Types for C++. (line 6) 49219* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 49220* TYPENAME_TYPE_FULLNAME: Types. (line 6) 49221* TYPEOF_TYPE: Types for C++. (line 6) 49222* UDAmode: Machine Modes. (line 168) 49223* udiv: Arithmetic. (line 130) 49224* udivM3 instruction pattern: Standard Names. (line 269) 49225* udivmodM4 instruction pattern: Standard Names. (line 507) 49226* udot_prodM instruction pattern: Standard Names. (line 335) 49227* UDQmode: Machine Modes. (line 136) 49228* UHAmode: Machine Modes. (line 160) 49229* UHQmode: Machine Modes. (line 128) 49230* UINT16_TYPE: Type Layout. (line 258) 49231* UINT32_TYPE: Type Layout. (line 259) 49232* UINT64_TYPE: Type Layout. (line 260) 49233* UINT8_TYPE: Type Layout. (line 257) 49234* UINT_FAST16_TYPE: Type Layout. (line 274) 49235* UINT_FAST32_TYPE: Type Layout. (line 275) 49236* UINT_FAST64_TYPE: Type Layout. (line 276) 49237* UINT_FAST8_TYPE: Type Layout. (line 273) 49238* UINT_LEAST16_TYPE: Type Layout. (line 266) 49239* UINT_LEAST32_TYPE: Type Layout. (line 267) 49240* UINT_LEAST64_TYPE: Type Layout. (line 268) 49241* UINT_LEAST8_TYPE: Type Layout. (line 265) 49242* UINTMAX_TYPE: Type Layout. (line 241) 49243* UINTPTR_TYPE: Type Layout. (line 278) 49244* umaddMN4 instruction pattern: Standard Names. (line 454) 49245* umax: Arithmetic. (line 149) 49246* umaxM3 instruction pattern: Standard Names. (line 269) 49247* umin: Arithmetic. (line 149) 49248* uminM3 instruction pattern: Standard Names. (line 269) 49249* umod: Arithmetic. (line 136) 49250* umodM3 instruction pattern: Standard Names. (line 269) 49251* umsubMN4 instruction pattern: Standard Names. (line 478) 49252* umulhisi3 instruction pattern: Standard Names. (line 426) 49253* umulM3_highpart instruction pattern: Standard Names. (line 440) 49254* umulqihi3 instruction pattern: Standard Names. (line 426) 49255* umulsidi3 instruction pattern: Standard Names. (line 426) 49256* unchanging: Flags. (line 296) 49257* unchanging, in call_insn: Flags. (line 19) 49258* unchanging, in jump_insn, call_insn and insn: Flags. (line 39) 49259* unchanging, in mem: Flags. (line 134) 49260* unchanging, in subreg: Flags. (line 170) 49261* unchanging, in symbol_ref: Flags. (line 10) 49262* UNEQ_EXPR: Unary and Binary Expressions. 49263 (line 6) 49264* UNGE_EXPR: Unary and Binary Expressions. 49265 (line 6) 49266* UNGT_EXPR: Unary and Binary Expressions. 49267 (line 6) 49268* UNION_TYPE <1>: Classes. (line 6) 49269* UNION_TYPE: Types. (line 6) 49270* unions, returning: Interface. (line 10) 49271* UNITS_PER_WORD: Storage Layout. (line 66) 49272* UNKNOWN_TYPE <1>: Types for C++. (line 6) 49273* UNKNOWN_TYPE: Types. (line 6) 49274* UNLE_EXPR: Unary and Binary Expressions. 49275 (line 6) 49276* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49) 49277* UNLT_EXPR: Unary and Binary Expressions. 49278 (line 6) 49279* UNORDERED_EXPR: Unary and Binary Expressions. 49280 (line 6) 49281* unshare_all_rtl: Sharing. (line 58) 49282* unsigned division: Arithmetic. (line 130) 49283* unsigned division with unsigned saturation: Arithmetic. (line 130) 49284* unsigned greater than: Comparisons. (line 64) 49285* unsigned less than: Comparisons. (line 68) 49286* unsigned minimum and maximum: Arithmetic. (line 149) 49287* unsigned_fix: Conversions. (line 77) 49288* unsigned_float: Conversions. (line 62) 49289* unsigned_fract_convert: Conversions. (line 97) 49290* unsigned_sat_fract: Conversions. (line 103) 49291* unspec <1>: Constant Definitions. 49292 (line 111) 49293* unspec: Side Effects. (line 293) 49294* unspec_volatile <1>: Constant Definitions. 49295 (line 99) 49296* unspec_volatile: Side Effects. (line 293) 49297* untyped_call instruction pattern: Standard Names. (line 1145) 49298* untyped_return instruction pattern: Standard Names. (line 1209) 49299* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 49300* update_ssa: SSA. (line 76) 49301* update_stmt <1>: SSA Operands. (line 6) 49302* update_stmt: Manipulating GIMPLE statements. 49303 (line 141) 49304* update_stmt_if_modified: Manipulating GIMPLE statements. 49305 (line 144) 49306* UQQmode: Machine Modes. (line 123) 49307* us_ashift: Arithmetic. (line 173) 49308* us_minus: Arithmetic. (line 36) 49309* us_mult: Arithmetic. (line 92) 49310* us_neg: Arithmetic. (line 81) 49311* us_plus: Arithmetic. (line 14) 49312* us_truncate: Conversions. (line 48) 49313* usaddM3 instruction pattern: Standard Names. (line 269) 49314* USAmode: Machine Modes. (line 164) 49315* usashlM3 instruction pattern: Standard Names. (line 510) 49316* usdivM3 instruction pattern: Standard Names. (line 269) 49317* use: Side Effects. (line 168) 49318* USE_C_ALLOCA: Host Misc. (line 19) 49319* USE_LD_AS_NEEDED: Driver. (line 136) 49320* USE_LOAD_POST_DECREMENT: Costs. (line 226) 49321* USE_LOAD_POST_INCREMENT: Costs. (line 221) 49322* USE_LOAD_PRE_DECREMENT: Costs. (line 236) 49323* USE_LOAD_PRE_INCREMENT: Costs. (line 231) 49324* use_param: GTY Options. (line 114) 49325* use_paramN: GTY Options. (line 132) 49326* use_params: GTY Options. (line 140) 49327* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 194) 49328* USE_STORE_POST_DECREMENT: Costs. (line 246) 49329* USE_STORE_POST_INCREMENT: Costs. (line 241) 49330* USE_STORE_PRE_DECREMENT: Costs. (line 256) 49331* USE_STORE_PRE_INCREMENT: Costs. (line 251) 49332* used: Flags. (line 314) 49333* used, in symbol_ref: Flags. (line 197) 49334* user: GTY Options. (line 301) 49335* user gc: User GC. (line 6) 49336* USER_LABEL_PREFIX: Instruction Output. (line 154) 49337* USING_STMT: Statements for C++. (line 6) 49338* usmaddMN4 instruction pattern: Standard Names. (line 462) 49339* usmsubMN4 instruction pattern: Standard Names. (line 486) 49340* usmulhisi3 instruction pattern: Standard Names. (line 430) 49341* usmulM3 instruction pattern: Standard Names. (line 269) 49342* usmulqihi3 instruction pattern: Standard Names. (line 430) 49343* usmulsidi3 instruction pattern: Standard Names. (line 430) 49344* usnegM2 instruction pattern: Standard Names. (line 532) 49345* USQmode: Machine Modes. (line 132) 49346* ussubM3 instruction pattern: Standard Names. (line 269) 49347* usum_widenM3 instruction pattern: Standard Names. (line 345) 49348* UTAmode: Machine Modes. (line 172) 49349* UTQmode: Machine Modes. (line 140) 49350* V in constraint: Simple Constraints. (line 43) 49351* VA_ARG_EXPR: Unary and Binary Expressions. 49352 (line 6) 49353* values, returned by functions: Scalar Return. (line 6) 49354* VAR_DECL: Declarations. (line 6) 49355* var_location: Debug Information. (line 14) 49356* varargs implementation: Varargs. (line 6) 49357* variable: Declarations. (line 6) 49358* Variable Location Debug Information in RTL: Debug Information. 49359 (line 6) 49360* variable_size: GTY Options. (line 230) 49361* vashlM3 instruction pattern: Standard Names. (line 524) 49362* vashrM3 instruction pattern: Standard Names. (line 524) 49363* vcondMN instruction pattern: Standard Names. (line 214) 49364* vec_concat: Vector Operations. (line 28) 49365* vec_duplicate: Vector Operations. (line 33) 49366* vec_extractM instruction pattern: Standard Names. (line 204) 49367* vec_initM instruction pattern: Standard Names. (line 209) 49368* vec_load_lanesMN instruction pattern: Standard Names. (line 166) 49369* VEC_LSHIFT_EXPR: Vectors. (line 6) 49370* vec_merge: Vector Operations. (line 11) 49371* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 49372* VEC_PACK_SAT_EXPR: Vectors. (line 6) 49373* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 372) 49374* vec_pack_ssat_M instruction pattern: Standard Names. (line 365) 49375* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 49376* vec_pack_trunc_M instruction pattern: Standard Names. (line 358) 49377* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 372) 49378* vec_pack_usat_M instruction pattern: Standard Names. (line 365) 49379* vec_perm_constM instruction pattern: Standard Names. (line 242) 49380* vec_permM instruction pattern: Standard Names. (line 224) 49381* VEC_RSHIFT_EXPR: Vectors. (line 6) 49382* vec_select: Vector Operations. (line 19) 49383* vec_setM instruction pattern: Standard Names. (line 199) 49384* vec_shl_M instruction pattern: Standard Names. (line 352) 49385* vec_shr_M instruction pattern: Standard Names. (line 352) 49386* vec_store_lanesMN instruction pattern: Standard Names. (line 188) 49387* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 49388* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 49389* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 49390* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 49391* vec_unpacks_float_hi_M instruction pattern: Standard Names. 49392 (line 394) 49393* vec_unpacks_float_lo_M instruction pattern: Standard Names. 49394 (line 394) 49395* vec_unpacks_hi_M instruction pattern: Standard Names. (line 379) 49396* vec_unpacks_lo_M instruction pattern: Standard Names. (line 379) 49397* vec_unpacku_float_hi_M instruction pattern: Standard Names. 49398 (line 394) 49399* vec_unpacku_float_lo_M instruction pattern: Standard Names. 49400 (line 394) 49401* vec_unpacku_hi_M instruction pattern: Standard Names. (line 387) 49402* vec_unpacku_lo_M instruction pattern: Standard Names. (line 387) 49403* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 49404* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 49405* vec_widen_smult_even_M instruction pattern: Standard Names. 49406 (line 403) 49407* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 403) 49408* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 403) 49409* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 403) 49410* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 49411 (line 412) 49412* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 49413 (line 412) 49414* vec_widen_umult_even_M instruction pattern: Standard Names. 49415 (line 403) 49416* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 403) 49417* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 403) 49418* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 403) 49419* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 49420 (line 412) 49421* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 49422 (line 412) 49423* vector: Containers. (line 6) 49424* vector operations: Vector Operations. (line 6) 49425* VECTOR_CST: Constant expressions. 49426 (line 6) 49427* VECTOR_STORE_FLAG_VALUE: Misc. (line 294) 49428* verify_flow_info: Maintaining the CFG. 49429 (line 119) 49430* virtual operands: SSA Operands. (line 6) 49431* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 49432* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 49433* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 49434* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 49435* VLIW: Processor pipeline description. 49436 (line 6) 49437* vlshrM3 instruction pattern: Standard Names. (line 524) 49438* VMS: Filesystem. (line 37) 49439* VMS_DEBUGGING_INFO: VMS Debug. (line 9) 49440* VOID_TYPE: Types. (line 6) 49441* VOIDmode: Machine Modes. (line 190) 49442* volatil: Flags. (line 328) 49443* volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags. 49444 (line 44) 49445* volatil, in label_ref and reg_label: Flags. (line 65) 49446* volatil, in mem, asm_operands, and asm_input: Flags. (line 76) 49447* volatil, in reg: Flags. (line 98) 49448* volatil, in subreg: Flags. (line 170) 49449* volatil, in symbol_ref: Flags. (line 206) 49450* volatile memory references: Flags. (line 329) 49451* volatile, in prefetch: Flags. (line 214) 49452* voting between constraint alternatives: Class Preferences. (line 6) 49453* vrotlM3 instruction pattern: Standard Names. (line 524) 49454* vrotrM3 instruction pattern: Standard Names. (line 524) 49455* walk_dominator_tree: SSA. (line 254) 49456* walk_gimple_op: Statement and operand traversals. 49457 (line 32) 49458* walk_gimple_seq: Statement and operand traversals. 49459 (line 50) 49460* walk_gimple_stmt: Statement and operand traversals. 49461 (line 13) 49462* walk_use_def_chains: SSA. (line 230) 49463* WCHAR_TYPE: Type Layout. (line 209) 49464* WCHAR_TYPE_SIZE: Type Layout. (line 217) 49465* which_alternative: Output Statement. (line 59) 49466* WHILE_BODY: Statements for C++. (line 6) 49467* WHILE_COND: Statements for C++. (line 6) 49468* WHILE_STMT: Statements for C++. (line 6) 49469* whopr: LTO. (line 6) 49470* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 154) 49471* window_save instruction pattern: Standard Names. (line 1513) 49472* WINT_TYPE: Type Layout. (line 222) 49473* word_mode: Machine Modes. (line 336) 49474* WORD_REGISTER_OPERATIONS: Misc. (line 54) 49475* WORDS_BIG_ENDIAN: Storage Layout. (line 29) 49476* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217) 49477* wpa: LTO. (line 6) 49478* X in constraint: Simple Constraints. (line 124) 49479* x-HOST: Host Fragment. (line 6) 49480* XCmode: Machine Modes. (line 197) 49481* XCOFF_DEBUGGING_INFO: DBX Options. (line 13) 49482* XEXP: Accessors. (line 6) 49483* XF_SIZE: Type Layout. (line 138) 49484* XFmode: Machine Modes. (line 79) 49485* XINT: Accessors. (line 6) 49486* xm-MACHINE.h <1>: Host Misc. (line 6) 49487* xm-MACHINE.h: Filesystem. (line 6) 49488* xor: Arithmetic. (line 168) 49489* xor, canonicalization of: Insn Canonicalizations. 49490 (line 79) 49491* xorM3 instruction pattern: Standard Names. (line 269) 49492* XSTR: Accessors. (line 6) 49493* XVEC: Accessors. (line 41) 49494* XVECEXP: Accessors. (line 48) 49495* XVECLEN: Accessors. (line 44) 49496* XWINT: Accessors. (line 6) 49497* zero_extend: Conversions. (line 28) 49498* zero_extendMN2 instruction pattern: Standard Names. (line 913) 49499* zero_extract: Bit-Fields. (line 30) 49500* zero_extract, canonicalization of: Insn Canonicalizations. 49501 (line 88) 49502 49503 49504 49505Tag Table: 49506Node: Top1842 49507Node: Contributing4930 49508Node: Portability5671 49509Node: Interface7459 49510Node: Libgcc10499 49511Node: Integer library routines12340 49512Node: Soft float library routines19182 49513Node: Decimal float library routines31119 49514Node: Fixed-point fractional library routines46876 49515Node: Exception handling routines147274 49516Node: Miscellaneous routines148381 49517Node: Languages150501 49518Node: Source Tree152050 49519Node: Configure Terms152632 49520Node: Top Level155590 49521Node: gcc Directory159164 49522Node: Subdirectories160114 49523Node: Configuration162281 49524Node: Config Fragments163001 49525Node: System Config164230 49526Node: Configuration Files165166 49527Node: Build167991 49528Node: Makefile168403 49529Ref: Makefile-Footnote-1175206 49530Ref: Makefile-Footnote-2175351 49531Node: Library Files175423 49532Node: Headers175985 49533Node: Documentation178068 49534Node: Texinfo Manuals178927 49535Node: Man Page Generation181260 49536Node: Miscellaneous Docs183175 49537Node: Front End184569 49538Node: Front End Directory188262 49539Node: Front End Config189582 49540Node: Front End Makefile192408 49541Node: Back End196190 49542Node: Testsuites199987 49543Node: Test Idioms200918 49544Node: Test Directives204315 49545Node: Directives204842 49546Node: Selectors215152 49547Node: Effective-Target Keywords216510 49548Ref: arm_neon_ok224125 49549Ref: arm_neonv2_ok224283 49550Ref: arm_neon_fp16_ok224455 49551Node: Add Options234826 49552Node: Require Support236023 49553Node: Final Actions238530 49554Node: Ada Tests243697 49555Node: C Tests245029 49556Node: libgcj Tests249452 49557Node: LTO Testing250579 49558Node: gcov Testing252226 49559Node: profopt Testing255213 49560Node: compat Testing256928 49561Node: Torture Tests261168 49562Node: Options262785 49563Node: Option file format263225 49564Node: Option properties270215 49565Node: Passes283094 49566Node: Parsing pass283838 49567Node: Gimplification pass287368 49568Node: Pass manager289201 49569Node: Tree SSA passes290995 49570Node: RTL passes313467 49571Node: RTL326598 49572Node: RTL Objects328786 49573Node: RTL Classes332660 49574Node: Accessors337658 49575Node: Special Accessors340052 49576Node: Flags345822 49577Node: Machine Modes360546 49578Node: Constants372858 49579Node: Regs and Memory379588 49580Node: Arithmetic397489 49581Node: Comparisons407579 49582Node: Bit-Fields411871 49583Node: Vector Operations413423 49584Node: Conversions415305 49585Node: RTL Declarations419803 49586Node: Side Effects420624 49587Node: Incdec437224 49588Node: Assembler440559 49589Node: Debug Information442104 49590Node: Insns443302 49591Node: Calls469796 49592Node: Sharing472389 49593Node: Reading RTL475499 49594Node: GENERIC476491 49595Node: Deficiencies478364 49596Node: Tree overview478605 49597Node: Macros and Functions482732 49598Node: Identifiers483557 49599Node: Containers485168 49600Node: Types486325 49601Node: Declarations498421 49602Node: Working with declarations498916 49603Node: Internal structure504522 49604Node: Current structure hierarchy504906 49605Node: Adding new DECL node types507000 49606Node: Attributes511073 49607Node: Expression trees512318 49608Node: Constant expressions514071 49609Node: Storage References518290 49610Node: Unary and Binary Expressions521809 49611Node: Vectors541671 49612Node: Statements546398 49613Node: Basic Statements546918 49614Node: Blocks551425 49615Node: Statement Sequences552829 49616Node: Empty Statements553162 49617Node: Jumps553736 49618Node: Cleanups554389 49619Node: OpenMP556157 49620Node: Functions561997 49621Node: Function Basics562468 49622Node: Function Properties566153 49623Node: Language-dependent trees568935 49624Node: C and C++ Trees569821 49625Node: Types for C++572725 49626Node: Namespaces577703 49627Node: Classes580810 49628Node: Functions for C++585888 49629Node: Statements for C++592141 49630Node: C++ Expressions600189 49631Node: Java Trees601690 49632Node: GIMPLE601803 49633Node: Tuple representation605424 49634Node: GIMPLE instruction set613700 49635Node: GIMPLE Exception Handling615368 49636Node: Temporaries617282 49637Ref: Temporaries-Footnote-1618597 49638Node: Operands618660 49639Node: Compound Expressions619422 49640Node: Compound Lvalues619656 49641Node: Conditional Expressions620418 49642Node: Logical Operators621076 49643Node: Manipulating GIMPLE statements627833 49644Node: Tuple specific accessors633767 49645Node: `GIMPLE_ASM'634586 49646Node: `GIMPLE_ASSIGN'637219 49647Node: `GIMPLE_BIND'641325 49648Node: `GIMPLE_CALL'643132 49649Node: `GIMPLE_CATCH'647402 49650Node: `GIMPLE_COND'648546 49651Node: `GIMPLE_DEBUG'651334 49652Node: `GIMPLE_EH_FILTER'654717 49653Node: `GIMPLE_LABEL'656205 49654Node: `GIMPLE_NOP'657180 49655Node: `GIMPLE_OMP_ATOMIC_LOAD'657549 49656Node: `GIMPLE_OMP_ATOMIC_STORE'658459 49657Node: `GIMPLE_OMP_CONTINUE'659098 49658Node: `GIMPLE_OMP_CRITICAL'660448 49659Node: `GIMPLE_OMP_FOR'661385 49660Node: `GIMPLE_OMP_MASTER'664900 49661Node: `GIMPLE_OMP_ORDERED'665283 49662Node: `GIMPLE_OMP_PARALLEL'665683 49663Node: `GIMPLE_OMP_RETURN'668455 49664Node: `GIMPLE_OMP_SECTION'669105 49665Node: `GIMPLE_OMP_SECTIONS'669771 49666Node: `GIMPLE_OMP_SINGLE'671377 49667Node: `GIMPLE_PHI'672314 49668Node: `GIMPLE_RESX'673600 49669Node: `GIMPLE_RETURN'674319 49670Node: `GIMPLE_SWITCH'674887 49671Node: `GIMPLE_TRY'676687 49672Node: `GIMPLE_WITH_CLEANUP_EXPR'678477 49673Node: GIMPLE sequences679360 49674Node: Sequence iterators682566 49675Node: Adding a new GIMPLE statement code691022 49676Node: Statement and operand traversals692298 49677Node: Tree SSA694898 49678Node: Annotations696684 49679Node: SSA Operands697210 49680Node: SSA711741 49681Node: Alias analysis723861 49682Node: Memory model727641 49683Node: Loop Analysis and Representation729004 49684Node: Loop representation730185 49685Node: Loop querying737105 49686Node: Loop manipulation739938 49687Node: LCSSA742306 49688Node: Scalar evolutions744378 49689Node: loop-iv747622 49690Node: Number of iterations749548 49691Node: Dependency analysis752357 49692Node: Lambda758725 49693Node: Omega760396 49694Node: Control Flow761961 49695Node: Basic Blocks763727 49696Node: Edges769018 49697Node: Profile information777650 49698Node: Maintaining the CFG782334 49699Node: Liveness information788196 49700Node: Machine Desc790322 49701Node: Overview792885 49702Node: Patterns794926 49703Node: Example798364 49704Node: RTL Template799799 49705Node: Output Template810454 49706Node: Output Statement814419 49707Node: Predicates818758 49708Node: Machine-Independent Predicates821676 49709Node: Defining Predicates826621 49710Node: Constraints832586 49711Node: Simple Constraints834068 49712Node: Multi-Alternative846924 49713Node: Class Preferences849765 49714Node: Modifiers850657 49715Node: Machine Constraints854903 49716Node: Disable Insn Alternatives907311 49717Node: Define Constraints910213 49718Node: C Constraint Interface917000 49719Node: Standard Names920641 49720Ref: shift patterns943192 49721Ref: prologue instruction pattern988132 49722Ref: window_save instruction pattern988625 49723Ref: epilogue instruction pattern988900 49724Node: Pattern Ordering1006471 49725Node: Dependent Patterns1007707 49726Node: Jump Patterns1009327 49727Ref: Jump Patterns-Footnote-11011471 49728Node: Looping Patterns1011517 49729Node: Insn Canonicalizations1016245 49730Node: Expander Definitions1020836 49731Node: Insn Splitting1029048 49732Node: Including Patterns1038650 49733Node: Peephole Definitions1040430 49734Node: define_peephole1041683 49735Node: define_peephole21048014 49736Node: Insn Attributes1051081 49737Node: Defining Attributes1052187 49738Ref: define_enum_attr1055398 49739Node: Expressions1056433 49740Node: Tagging Insns1063182 49741Node: Attr Example1067535 49742Node: Insn Lengths1069909 49743Node: Constant Attributes1072986 49744Node: Delay Slots1074155 49745Node: Processor pipeline description1077379 49746Ref: Processor pipeline description-Footnote-11096192 49747Node: Conditional Execution1096514 49748Node: Define Subst1099576 49749Node: Define Subst Example1101610 49750Node: Define Subst Pattern Matching1104604 49751Node: Define Subst Output Template1105829 49752Node: Constant Definitions1107899 49753Ref: define_enum1111681 49754Node: Iterators1112169 49755Node: Mode Iterators1112747 49756Node: Defining Mode Iterators1113725 49757Node: Substitutions1115219 49758Node: Examples1117460 49759Node: Code Iterators1118908 49760Node: Int Iterators1121187 49761Node: Subst Iterators1123645 49762Node: Target Macros1125337 49763Node: Target Structure1128425 49764Node: Driver1130540 49765Node: Run-time Target1149323 49766Node: Per-Function Data1158476 49767Node: Storage Layout1161241 49768Node: Type Layout1187316 49769Node: Registers1202643 49770Node: Register Basics1203617 49771Node: Allocation Order1209122 49772Node: Values in Registers1211568 49773Node: Leaf Functions1219057 49774Node: Stack Registers1221915 49775Node: Register Classes1223187 49776Node: Old Constraints1253192 49777Node: Stack and Calling1260344 49778Node: Frame Layout1260878 49779Node: Exception Handling1271758 49780Node: Stack Checking1277980 49781Node: Frame Registers1282793 49782Node: Elimination1291052 49783Node: Stack Arguments1295281 49784Node: Register Arguments1302464 49785Node: Scalar Return1322558 49786Node: Aggregate Return1328644 49787Node: Caller Saves1332854 49788Node: Function Entry1334032 49789Node: Profiling1345136 49790Node: Tail Calls1346835 49791Node: Stack Smashing Protection1348738 49792Node: Varargs1350366 49793Node: Trampolines1357062 49794Node: Library Calls1363105 49795Node: Addressing Modes1368044 49796Node: Anchored Addresses1388078 49797Node: Condition Code1390727 49798Node: CC0 Condition Codes1392786 49799Node: MODE_CC Condition Codes1396032 49800Node: Costs1402899 49801Node: Scheduling1419368 49802Node: Sections1438774 49803Node: PIC1454472 49804Node: Assembler Format1456532 49805Node: File Framework1457670 49806Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1464611 49807Node: Data Output1467876 49808Node: Uninitialized Data1475652 49809Node: Label Output1480663 49810Node: Initialization1503631 49811Node: Macros for Initialization1509593 49812Node: Instruction Output1516316 49813Node: Dispatch Tables1526818 49814Node: Exception Region Output1531196 49815Node: Alignment Output1537879 49816Node: Debugging Info1542424 49817Node: All Debuggers1543094 49818Node: DBX Options1545949 49819Node: DBX Hooks1551398 49820Node: File Names and DBX1552707 49821Node: SDB and DWARF1554819 49822Node: VMS Debug1560891 49823Node: Floating Point1561478 49824Node: Mode Switching1565954 49825Node: Target Attributes1569950 49826Node: Emulated TLS1578264 49827Node: MIPS Coprocessors1581654 49828Node: PCH Target1582951 49829Node: C++ ABI1584793 49830Node: Named Address Spaces1589585 49831Node: Misc1594524 49832Ref: TARGET_SHIFT_TRUNCATION_MASK1601266 49833Node: Host Config1646432 49834Node: Host Common1647500 49835Node: Filesystem1649879 49836Node: Host Misc1653994 49837Node: Fragments1656443 49838Node: Target Fragment1657638 49839Node: Host Fragment1668271 49840Node: Collect21668511 49841Node: Header Dirs1671147 49842Node: Type Information1672570 49843Node: GTY Options1675793 49844Node: User GC1690114 49845Node: GGC Roots1693841 49846Node: Files1694557 49847Node: Invoking the garbage collector1697264 49848Node: Troubleshooting1698767 49849Node: Plugins1699843 49850Node: Plugins loading1700961 49851Node: Plugin API1701830 49852Node: Plugins pass1708859 49853Node: Plugins GC1710828 49854Node: Plugins description1712488 49855Node: Plugins attr1713023 49856Node: Plugins recording1714908 49857Node: Plugins gate1715758 49858Node: Plugins tracking1716349 49859Node: Plugins building1716937 49860Node: LTO1718723 49861Node: LTO Overview1719584 49862Node: LTO object file layout1725416 49863Node: IPA1730048 49864Node: WHOPR1739013 49865Node: Internal flags1743704 49866Node: Funding1744916 49867Node: GNU Project1747399 49868Node: Copying1748048 49869Node: GNU Free Documentation License1785579 49870Node: Contributors1810719 49871Node: Option Index1848124 49872Node: Concept Index1848928 49873 49874End Tag Table 49875