1This is doc/gccint.info, produced by makeinfo version 4.7 from 2/home/mitchell/gcc-3.4.2/gcc-3.4.2/gcc/doc/gccint.texi. 3 4 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 51999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. 6 7 Permission is granted to copy, distribute and/or modify this document 8under the terms of the GNU Free Documentation License, Version 1.2 or 9any later version published by the Free Software Foundation; with the 10Invariant Sections being "GNU General Public License" and "Funding Free 11Software", the Front-Cover texts being (a) (see below), and with the 12Back-Cover Texts being (b) (see below). A copy of the license is 13included in the section entitled "GNU Free Documentation License". 14 15 (a) The FSF's Front-Cover Text is: 16 17 A GNU Manual 18 19 (b) The FSF's Back-Cover Text is: 20 21 You have freedom to copy and modify this GNU Manual, like GNU 22software. Copies published by the Free Software Foundation raise 23funds for GNU development. 24 25INFO-DIR-SECTION Programming 26START-INFO-DIR-ENTRY 27* gccint: (gccint). Internals of the GNU Compiler Collection. 28END-INFO-DIR-ENTRY 29 This file documents the internals of the GNU compilers. 30 31 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 321999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. 33 34 Permission is granted to copy, distribute and/or modify this document 35under the terms of the GNU Free Documentation License, Version 1.2 or 36any later version published by the Free Software Foundation; with the 37Invariant Sections being "GNU General Public License" and "Funding Free 38Software", the Front-Cover texts being (a) (see below), and with the 39Back-Cover Texts being (b) (see below). A copy of the license is 40included in the section entitled "GNU Free Documentation License". 41 42 (a) The FSF's Front-Cover Text is: 43 44 A GNU Manual 45 46 (b) The FSF's Back-Cover Text is: 47 48 You have freedom to copy and modify this GNU Manual, like GNU 49software. Copies published by the Free Software Foundation raise 50funds for GNU development. 51 52 53File: gccint.info, Node: Top, Next: Contributing, Up: (DIR) 54 55Introduction 56************ 57 58This manual documents the internals of the GNU compilers, including how 59to port them to new targets and some information about how to write 60front ends for new languages. It corresponds to GCC version 3.4.2. 61The use of the GNU compilers is documented in a separate manual. *Note 62Introduction: (gcc)Top. 63 64 This manual is mainly a reference manual rather than a tutorial. It 65discusses how to contribute to GCC (*note Contributing::), the 66characteristics of the machines supported by GCC as hosts and targets 67(*note Portability::), how GCC relates to the ABIs on such systems 68(*note Interface::), and the characteristics of the languages for which 69GCC front ends are written (*note Languages::). It then describes the 70GCC source tree structure and build system, some of the interfaces to 71GCC front ends, and how support for a target system is implemented in 72GCC. 73 74 Additional tutorial information is linked to from 75`http://gcc.gnu.org/readings.html'. 76 77* Menu: 78 79* Contributing:: How to contribute to testing and developing GCC. 80* Portability:: Goals of GCC's portability features. 81* Interface:: Function-call interface of GCC output. 82* Libgcc:: Low-level runtime library used by GCC. 83* Languages:: Languages for which GCC front ends are written. 84* Source Tree:: GCC source tree structure and build system. 85* Passes:: Order of passes, what they do, and what each file is for. 86* Trees:: The source representation used by the C and C++ front ends. 87* RTL:: The intermediate representation that most passes work on. 88* Machine Desc:: How to write machine description instruction patterns. 89* Target Macros:: How to write the machine description C macros and functions. 90* Host Config:: Writing the `xm-MACHINE.h' file. 91* Fragments:: Writing the `t-TARGET' and `x-HOST' files. 92* Collect2:: How `collect2' works; how it finds `ld'. 93* Header Dirs:: Understanding the standard header file directories. 94* Type Information:: GCC's memory management; generating type information. 95 96* Funding:: How to help assure funding for free software. 97* GNU Project:: The GNU Project and GNU/Linux. 98 99* Copying:: GNU General Public License says 100 how you can copy and share GCC. 101* GNU Free Documentation License:: How you can copy and share this manual. 102* Contributors:: People who have contributed to GCC. 103 104* Option Index:: Index to command line options. 105* Index:: Index of concepts and symbol names. 106 107 108File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top 109 1101 Contributing to GCC Development 111********************************* 112 113If you would like to help pretest GCC releases to assure they work well, 114current development sources are available by CVS (see 115`http://gcc.gnu.org/cvs.html'). Source and binary snapshots are also 116available for FTP; see `http://gcc.gnu.org/snapshots.html'. 117 118 If you would like to work on improvements to GCC, please read the 119advice at these URLs: 120 121 `http://gcc.gnu.org/contribute.html' 122 `http://gcc.gnu.org/contributewhy.html' 123 124for information on how to make useful contributions and avoid 125duplication of effort. Suggested projects are listed at 126`http://gcc.gnu.org/projects/'. 127 128 129File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 130 1312 GCC and Portability 132********************* 133 134GCC itself aims to be portable to any machine where `int' is at least a 13532-bit type. It aims to target machines with a flat (non-segmented) 136byte addressed data address space (the code address space can be 137separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char' 138can be wider than 8 bits. 139 140 GCC gets most of the information about the target machine from a 141machine description which gives an algebraic formula for each of the 142machine's instructions. This is a very clean way to describe the 143target. But when the compiler needs information that is difficult to 144express in this fashion, ad-hoc parameters have been defined for 145machine descriptions. The purpose of portability is to reduce the 146total work needed on the compiler; it was not of interest for its own 147sake. 148 149 GCC does not contain machine dependent code, but it does contain code 150that depends on machine parameters such as endianness (whether the most 151significant byte has the highest or lowest address of the bytes in a 152word) and the availability of autoincrement addressing. In the 153RTL-generation pass, it is often necessary to have multiple strategies 154for generating code for a particular kind of syntax tree, strategies 155that are usable for different combinations of parameters. Often, not 156all possible cases have been addressed, but only the common ones or 157only the ones that have been encountered. As a result, a new target 158may require additional strategies. You will know if this happens 159because the compiler will call `abort'. Fortunately, the new 160strategies can be added in a machine-independent fashion, and will 161affect only the target machines that need them. 162 163 164File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 165 1663 Interfacing to GCC Output 167*************************** 168 169GCC is normally configured to use the same function calling convention 170normally in use on the target system. This is done with the 171machine-description macros described (*note Target Macros::). 172 173 However, returning of structure and union values is done differently 174on some target machines. As a result, functions compiled with PCC 175returning such types cannot be called from code compiled with GCC, and 176vice versa. This does not cause trouble often because few Unix library 177routines return structures or unions. 178 179 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes 180long in the same registers used for `int' or `double' return values. 181(GCC typically allocates variables of such types in registers also.) 182Structures and unions of other sizes are returned by storing them into 183an address passed by the caller (usually in a register). The target 184hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 185 186 By contrast, PCC on most target machines returns structures and 187unions of any size by copying the data into an area of static storage, 188and then returning the address of that storage as if it were a pointer 189value. The caller must copy the data from that memory area to the 190place where the value is wanted. This is slower than the method used 191by GCC, and fails to be reentrant. 192 193 On some target machines, such as RISC machines and the 80386, the 194standard system convention is to pass to the subroutine the address of 195where to return the value. On these machines, GCC has been configured 196to be compatible with the standard compiler, when this method is used. 197It may not be compatible for structures of 1, 2, 4 or 8 bytes. 198 199 GCC uses the system's standard convention for passing arguments. On 200some machines, the first few arguments are passed in registers; in 201others, all are passed on the stack. It would be possible to use 202registers for argument passing on any machine, and this would probably 203result in a significant speedup. But the result would be complete 204incompatibility with code that follows the standard convention. So this 205change is practical only if you are switching to GCC as the sole C 206compiler for the system. We may implement register argument passing on 207certain machines once we have a complete GNU system so that we can 208compile the libraries with GCC. 209 210 On some machines (particularly the SPARC), certain types of arguments 211are passed "by invisible reference". This means that the value is 212stored in memory, and the address of the memory location is passed to 213the subroutine. 214 215 If you use `longjmp', beware of automatic variables. ISO C says that 216automatic variables that are not declared `volatile' have undefined 217values after a `longjmp'. And this is all GCC promises to do, because 218it is very difficult to restore register variables correctly, and one 219of GCC's features is that it can put variables in registers without 220your asking it to. 221 222 If you want a variable to be unaltered by `longjmp', and you don't 223want to write `volatile' because old C compilers don't accept it, just 224take the address of the variable. If a variable's address is ever 225taken, even if just to compute it and ignore it, then the variable 226cannot go in a register: 227 228 { 229 int careful; 230 &careful; 231 ... 232 } 233 234 235File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 236 2374 The GCC low-level runtime library 238*********************************** 239 240GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1' 241on some platforms. GCC generates calls to routines in this library 242automatically, whenever it needs to perform some operation that is too 243complicated to emit inline code for. 244 245 Most of the routines in `libgcc' handle arithmetic operations that 246the target processor cannot perform directly. This includes integer 247multiply and divide on some machines, and all floating-point operations 248on other machines. `libgcc' also includes routines for exception 249handling, and a handful of miscellaneous operations. 250 251 Some of these routines can be defined in mostly machine-independent 252C. Others must be hand-written in assembly language for each processor 253that needs them. 254 255 GCC will also generate calls to C library routines, such as `memcpy' 256and `memset', in some cases. The set of routines that GCC may possibly 257use is documented in *Note Other Builtins: (gcc)Other Builtins. 258 259 These routines take arguments and return values of a specific machine 260mode, not a specific C type. *Note Machine Modes::, for an explanation 261of this concept. For illustrative purposes, in this chapter the 262floating point type `float' is assumed to correspond to `SFmode'; 263`double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'. 264Similarly, the integer types `int' and `unsigned int' correspond to 265`SImode'; `long' and `unsigned long' to `DImode'; and `long long' and 266`unsigned long long' to `TImode'. 267 268* Menu: 269 270* Integer library routines:: 271* Soft float library routines:: 272* Exception handling routines:: 273* Miscellaneous routines:: 274 275 276File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 277 2784.1 Routines for integer arithmetic 279=================================== 280 281The integer arithmetic routines are used on platforms that don't provide 282hardware support for arithmetic operations on some modes. 283 2844.1.1 Arithmetic functions 285-------------------------- 286 287 -- Runtime Function: int __ashlsi3 (int A, int B) 288 -- Runtime Function: long __ashldi3 (long A, int B) 289 -- Runtime Function: long long __ashlti3 (long long A, int B) 290 These functions return the result of shifting A left by B bits. 291 292 -- Runtime Function: int __ashrsi3 (int A, int B) 293 -- Runtime Function: long __ashrdi3 (long A, int B) 294 -- Runtime Function: long long __ashrti3 (long long A, int B) 295 These functions return the result of arithmetically shifting A 296 right by B bits. 297 298 -- Runtime Function: int __divsi3 (int A, int B) 299 -- Runtime Function: long __divdi3 (long A, long B) 300 -- Runtime Function: long long __divti3 (long long A, long long B) 301 These functions return the quotient of the signed division of A and 302 B. 303 304 -- Runtime Function: int __lshrsi3 (int A, int B) 305 -- Runtime Function: long __lshrdi3 (long A, int B) 306 -- Runtime Function: long long __lshrti3 (long long A, int B) 307 These functions return the result of logically shifting A right by 308 B bits. 309 310 -- Runtime Function: int __modsi3 (int A, int B) 311 -- Runtime Function: long __moddi3 (long A, long B) 312 -- Runtime Function: long long __modti3 (long long A, long long B) 313 These functions return the remainder of the signed division of A 314 and B. 315 316 -- Runtime Function: int __mulsi3 (int A, int B) 317 -- Runtime Function: long __muldi3 (long A, long B) 318 -- Runtime Function: long long __multi3 (long long A, long long B) 319 These functions return the product of A and B. 320 321 -- Runtime Function: long __negdi2 (long A) 322 -- Runtime Function: long long __negti2 (long long A) 323 These functions return the negation of A. 324 325 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 326 int B) 327 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, 328 unsigned long B) 329 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 330 A, unsigned long long B) 331 These functions return the quotient of the unsigned division of A 332 and B. 333 334 -- Runtime Function: unsigned long __udivmoddi3 (unsigned long A, 335 unsigned long B, unsigned long *C) 336 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 337 A, unsigned long long B, unsigned long long *C) 338 These functions calculate both the quotient and remainder of the 339 unsigned division of A and B. The return value is the quotient, 340 and the remainder is placed in variable pointed to by C. 341 342 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 343 int B) 344 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, 345 unsigned long B) 346 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 347 A, unsigned long long B) 348 These functions return the remainder of the unsigned division of A 349 and B. 350 3514.1.2 Comparison functions 352-------------------------- 353 354The following functions implement integral comparisons. These functions 355implement a low-level compare, upon which the higher level comparison 356operators (such as less than and greater than or equal to) can be 357constructed. The returned values lie in the range zero to two, to allow 358the high-level operators to be implemented by testing the returned 359result using either signed or unsigned comparison. 360 361 -- Runtime Function: int __cmpdi2 (long A, long B) 362 -- Runtime Function: int __cmpti2 (long long A, long long B) 363 These functions perform a signed comparison of A and B. If A is 364 less than B, they return 0; if A is greater than B, they return 2; 365 and if A and B are equal they return 1. 366 367 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 368 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned 369 long long B) 370 These functions perform an unsigned comparison of A and B. If A 371 is less than B, they return 0; if A is greater than B, they return 372 2; and if A and B are equal they return 1. 373 3744.1.3 Trapping arithmetic functions 375----------------------------------- 376 377The following functions implement trapping arithmetic. These functions 378call the libc function `abort' upon signed arithmetic overflow. 379 380 -- Runtime Function: int __absvsi2 (int A) 381 -- Runtime Function: long __absvdi2 (long A) 382 These functions return the absolute value of A. 383 384 -- Runtime Function: int __addvsi3 (int A, int B) 385 -- Runtime Function: long __addvdi3 (long A, long B) 386 These functions return the sum of A and B; that is `A + B'. 387 388 -- Runtime Function: int __mulvsi3 (int A, int B) 389 -- Runtime Function: long __mulvdi3 (long A, long B) 390 The functions return the product of A and B; that is `A * B'. 391 392 -- Runtime Function: int __negvsi2 (int A) 393 -- Runtime Function: long __negvdi2 (long A) 394 These functions return the negation of A; that is `-A'. 395 396 -- Runtime Function: int __subvsi3 (int A, int B) 397 -- Runtime Function: long __subvdi3 (long A, long B) 398 These functions return the difference between B and A; that is `A 399 - B'. 400 4014.1.4 Bit operations 402-------------------- 403 404 -- Runtime Function: int __clzsi2 (int A) 405 -- Runtime Function: int __clzdi2 (long A) 406 -- Runtime Function: int __clzti2 (long long A) 407 These functions return the number of leading 0-bits in A, starting 408 at the most significant bit position. If A is zero, the result is 409 undefined. 410 411 -- Runtime Function: int __ctzsi2 (int A) 412 -- Runtime Function: int __ctzdi2 (long A) 413 -- Runtime Function: int __ctzti2 (long long A) 414 These functions return the number of trailing 0-bits in A, starting 415 at the least significant bit position. If A is zero, the result is 416 undefined. 417 418 -- Runtime Function: int __ffsdi2 (long A) 419 -- Runtime Function: int __ffsti2 (long long A) 420 These functions return the index of the least significant 1-bit in 421 A, or the value zero if A is zero. The least significant bit is 422 index one. 423 424 -- Runtime Function: int __paritysi2 (int A) 425 -- Runtime Function: int __paritydi2 (long A) 426 -- Runtime Function: int __parityti2 (long long A) 427 These functions return the value zero if the number of bits set in 428 A is even, and the value one otherwise. 429 430 -- Runtime Function: int __popcountsi2 (int A) 431 -- Runtime Function: int __popcountdi2 (long A) 432 -- Runtime Function: int __popcountti2 (long long A) 433 These functions return the number of bits set in A. 434 435 436File: gccint.info, Node: Soft float library routines, Next: Exception handling routines, Prev: Integer library routines, Up: Libgcc 437 4384.2 Routines for floating point emulation 439========================================= 440 441The software floating point library is used on machines which do not 442have hardware support for floating point. It is also used whenever 443`-msoft-float' is used to disable generation of floating point 444instructions. (Not all targets support this switch.) 445 446 For compatibility with other compilers, the floating point emulation 447routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note 448Library Calls::). In this section, the default names are used. 449 450 Presently the library does not support `XFmode', which is used for 451`long double' on some architectures. 452 4534.2.1 Arithmetic functions 454-------------------------- 455 456 -- Runtime Function: float __addsf3 (float A, float B) 457 -- Runtime Function: double __adddf3 (double A, double B) 458 -- Runtime Function: long double __addtf3 (long double A, long double 459 B) 460 -- Runtime Function: long double __addxf3 (long double A, long double 461 B) 462 These functions return the sum of A and B. 463 464 -- Runtime Function: float __subsf3 (float A, float B) 465 -- Runtime Function: double __subdf3 (double A, double B) 466 -- Runtime Function: long double __subtf3 (long double A, long double 467 B) 468 -- Runtime Function: long double __subxf3 (long double A, long double 469 B) 470 These functions return the difference between B and A; that is, 471 A - B. 472 473 -- Runtime Function: float __mulsf3 (float A, float B) 474 -- Runtime Function: double __muldf3 (double A, double B) 475 -- Runtime Function: long double __multf3 (long double A, long double 476 B) 477 -- Runtime Function: long double __mulxf3 (long double A, long double 478 B) 479 These functions return the product of A and B. 480 481 -- Runtime Function: float __divsf3 (float A, float B) 482 -- Runtime Function: double __divdf3 (double A, double B) 483 -- Runtime Function: long double __divtf3 (long double A, long double 484 B) 485 -- Runtime Function: long double __divxf3 (long double A, long double 486 B) 487 These functions return the quotient of A and B; that is, A / B. 488 489 -- Runtime Function: float __negsf2 (float A) 490 -- Runtime Function: double __negdf2 (double A) 491 -- Runtime Function: long double __negtf2 (long double A) 492 -- Runtime Function: long double __negxf2 (long double A) 493 These functions return the negation of A. They simply flip the 494 sign bit, so they can produce negative zero and negative NaN. 495 4964.2.2 Conversion functions 497-------------------------- 498 499 -- Runtime Function: double __extendsfdf2 (float A) 500 -- Runtime Function: long double __extendsftf2 (float A) 501 -- Runtime Function: long double __extendsfxf2 (float A) 502 -- Runtime Function: long double __extenddftf2 (double A) 503 -- Runtime Function: long double __extenddfxf2 (double A) 504 These functions extend A to the wider mode of their return type. 505 506 -- Runtime Function: double __truncxfdf2 (long double A) 507 -- Runtime Function: double __trunctfdf2 (long double A) 508 -- Runtime Function: float __truncxfsf2 (long double A) 509 -- Runtime Function: float __trunctfsf2 (long double A) 510 -- Runtime Function: float __truncdfsf2 (double A) 511 These functions truncate A to the narrower mode of their return 512 type, rounding toward zero. 513 514 -- Runtime Function: int __fixsfsi (float A) 515 -- Runtime Function: int __fixdfsi (double A) 516 -- Runtime Function: int __fixtfsi (long double A) 517 -- Runtime Function: int __fixxfsi (long double A) 518 These functions convert A to a signed integer, rounding toward 519 zero. 520 521 -- Runtime Function: long __fixsfdi (float A) 522 -- Runtime Function: long __fixdfdi (double A) 523 -- Runtime Function: long __fixtfdi (long double A) 524 -- Runtime Function: long __fixxfdi (long double A) 525 These functions convert A to a signed long, rounding toward zero. 526 527 -- Runtime Function: long long __fixsfti (float A) 528 -- Runtime Function: long long __fixdfti (double A) 529 -- Runtime Function: long long __fixtfti (long double A) 530 -- Runtime Function: long long __fixxfti (long double A) 531 These functions convert A to a signed long long, rounding toward 532 zero. 533 534 -- Runtime Function: unsigned int __fixunssfsi (float A) 535 -- Runtime Function: unsigned int __fixunsdfsi (double A) 536 -- Runtime Function: unsigned int __fixunstfsi (long double A) 537 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 538 These functions convert A to an unsigned integer, rounding toward 539 zero. Negative values all become zero. 540 541 -- Runtime Function: unsigned long __fixunssfdi (float A) 542 -- Runtime Function: unsigned long __fixunsdfdi (double A) 543 -- Runtime Function: unsigned long __fixunstfdi (long double A) 544 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 545 These functions convert A to an unsigned long, rounding toward 546 zero. Negative values all become zero. 547 548 -- Runtime Function: unsigned long long __fixunssfti (float A) 549 -- Runtime Function: unsigned long long __fixunsdfti (double A) 550 -- Runtime Function: unsigned long long __fixunstfti (long double A) 551 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 552 These functions convert A to an unsigned long long, rounding 553 toward zero. Negative values all become zero. 554 555 -- Runtime Function: float __floatsisf (int I) 556 -- Runtime Function: double __floatsidf (int I) 557 -- Runtime Function: long double __floatsitf (int I) 558 -- Runtime Function: long double __floatsixf (int I) 559 These functions convert I, a signed integer, to floating point. 560 561 -- Runtime Function: float __floatdisf (long I) 562 -- Runtime Function: double __floatdidf (long I) 563 -- Runtime Function: long double __floatditf (long I) 564 -- Runtime Function: long double __floatdixf (long I) 565 These functions convert I, a signed long, to floating point. 566 567 -- Runtime Function: float __floattisf (long long I) 568 -- Runtime Function: double __floattidf (long long I) 569 -- Runtime Function: long double __floattitf (long long I) 570 -- Runtime Function: long double __floattixf (long long I) 571 These functions convert I, a signed long long, to floating point. 572 5734.2.3 Comparison functions 574-------------------------- 575 576There are two sets of basic comparison functions. 577 578 -- Runtime Function: int __cmpsf2 (float A, float B) 579 -- Runtime Function: int __cmpdf2 (double A, double B) 580 -- Runtime Function: int __cmptf2 (long double A, long double B) 581 These functions calculate a <=> b. That is, if A is less than B, 582 they return -1; if A is greater than B, they return 1; and if A 583 and B are equal they return 0. If either argument is NaN they 584 return 1, but you should not rely on this; if NaN is a 585 possibility, use one of the higher-level comparison functions. 586 587 -- Runtime Function: int __unordsf2 (float A, float B) 588 -- Runtime Function: int __unorddf2 (double A, double B) 589 -- Runtime Function: int __unordtf2 (long double A, long double B) 590 These functions return a nonzero value if either argument is NaN, 591 otherwise 0. 592 593 There is also a complete group of higher level functions which 594correspond directly to comparison operators. They implement the ISO C 595semantics for floating-point comparisons, taking NaN into account. Pay 596careful attention to the return values defined for each set. Under the 597hood, all of these routines are implemented as 598 599 if (__unordXf2 (a, b)) 600 return E; 601 return __cmpXf2 (a, b); 602 603where E is a constant chosen to give the proper behavior for NaN. 604Thus, the meaning of the return value is different for each set. Do 605not rely on this implementation; only the semantics documented below 606are guaranteed. 607 608 -- Runtime Function: int __eqsf2 (float A, float B) 609 -- Runtime Function: int __eqdf2 (double A, double B) 610 -- Runtime Function: int __eqtf2 (long double A, long double B) 611 These functions return zero if neither argument is NaN, and A and 612 B are equal. 613 614 -- Runtime Function: int __nesf2 (float A, float B) 615 -- Runtime Function: int __nedf2 (double A, double B) 616 -- Runtime Function: int __netf2 (long double A, long double B) 617 These functions return a nonzero value if either argument is NaN, 618 or if A and B are unequal. 619 620 -- Runtime Function: int __gesf2 (float A, float B) 621 -- Runtime Function: int __gedf2 (double A, double B) 622 -- Runtime Function: int __getf2 (long double A, long double B) 623 These functions return a value greater than or equal to zero if 624 neither argument is NaN, and A is greater than or equal to B. 625 626 -- Runtime Function: int __ltsf2 (float A, float B) 627 -- Runtime Function: int __ltdf2 (double A, double B) 628 -- Runtime Function: int __lttf2 (long double A, long double B) 629 These functions return a value less than zero if neither argument 630 is NaN, and A is strictly less than B. 631 632 -- Runtime Function: int __lesf2 (float A, float B) 633 -- Runtime Function: int __ledf2 (double A, double B) 634 -- Runtime Function: int __letf2 (long double A, long double B) 635 These functions return a value less than or equal to zero if 636 neither argument is NaN, and A is less than or equal to B. 637 638 -- Runtime Function: int __gtsf2 (float A, float B) 639 -- Runtime Function: int __gtdf2 (double A, double B) 640 -- Runtime Function: int __gttf2 (long double A, long double B) 641 These functions return a value greater than zero if neither 642 argument is NaN, and A is strictly greater than B. 643 644 645File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Soft float library routines, Up: Libgcc 646 6474.3 Language-independent routines for exception handling 648======================================================== 649 650document me! 651 652 _Unwind_DeleteException 653 _Unwind_Find_FDE 654 _Unwind_ForcedUnwind 655 _Unwind_GetGR 656 _Unwind_GetIP 657 _Unwind_GetLanguageSpecificData 658 _Unwind_GetRegionStart 659 _Unwind_GetTextRelBase 660 _Unwind_GetDataRelBase 661 _Unwind_RaiseException 662 _Unwind_Resume 663 _Unwind_SetGR 664 _Unwind_SetIP 665 _Unwind_FindEnclosingFunction 666 _Unwind_SjLj_Register 667 _Unwind_SjLj_Unregister 668 _Unwind_SjLj_RaiseException 669 _Unwind_SjLj_ForcedUnwind 670 _Unwind_SjLj_Resume 671 __deregister_frame 672 __deregister_frame_info 673 __deregister_frame_info_bases 674 __register_frame 675 __register_frame_info 676 __register_frame_info_bases 677 __register_frame_info_table 678 __register_frame_info_table_bases 679 __register_frame_table 680 681 682File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 683 6844.4 Miscellaneous runtime library routines 685========================================== 686 6874.4.1 Cache control functions 688----------------------------- 689 690 -- Runtime Function: void __clear_cache (char *BEG, char *END) 691 This function clears the instruction cache between BEG and END. 692 693 694File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 695 6965 Language Front Ends in GCC 697**************************** 698 699The interface to front ends for languages in GCC, and in particular the 700`tree' structure (*note Trees::), was initially designed for C, and 701many aspects of it are still somewhat biased towards C and C-like 702languages. It is, however, reasonably well suited to other procedural 703languages, and front ends for many such languages have been written for 704GCC. 705 706 Writing a compiler as a front end for GCC, rather than compiling 707directly to assembler or generating C code which is then compiled by 708GCC, has several advantages: 709 710 * GCC front ends benefit from the support for many different target 711 machines already present in GCC. 712 713 * GCC front ends benefit from all the optimizations in GCC. Some of 714 these, such as alias analysis, may work better when GCC is 715 compiling directly from source code then when it is compiling from 716 generated C code. 717 718 * Better debugging information is generated when compiling directly 719 from source code than when going via intermediate generated C code. 720 721 Because of the advantages of writing a compiler as a GCC front end, 722GCC front ends have also been created for languages very different from 723those for which GCC was designed, such as the declarative 724logic/functional language Mercury. For these reasons, it may also be 725useful to implement compilers created for specialized purposes (for 726example, as part of a research project) as GCC front ends. 727 728 729File: gccint.info, Node: Source Tree, Next: Passes, Prev: Languages, Up: Top 730 7316 Source Tree Structure and Build System 732**************************************** 733 734This chapter describes the structure of the GCC source tree, and how 735GCC is built. The user documentation for building and installing GCC 736is in a separate manual (`http://gcc.gnu.org/install/'), with which it 737is presumed that you are familiar. 738 739* Menu: 740 741* Configure Terms:: Configuration terminology and history. 742* Top Level:: The top level source directory. 743* gcc Directory:: The `gcc' subdirectory. 744* Testsuites:: The GCC testsuites. 745 746 747File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 748 7496.1 Configure Terms and History 750=============================== 751 752The configure and build process has a long and colorful history, and can 753be confusing to anyone who doesn't know why things are the way they are. 754While there are other documents which describe the configuration process 755in detail, here are a few things that everyone working on GCC should 756know. 757 758 There are three system names that the build knows about: the machine 759you are building on ("build"), the machine that you are building for 760("host"), and the machine that GCC will produce code for ("target"). 761When you configure GCC, you specify these with `--build=', `--host=', 762and `--target='. 763 764 Specifying the host without specifying the build should be avoided, 765as `configure' may (and once did) assume that the host you specify is 766also the build, which may not be true. 767 768 If build, host, and target are all the same, this is called a 769"native". If build and host are the same but target is different, this 770is called a "cross". If build, host, and target are all different this 771is called a "canadian" (for obscure reasons dealing with Canada's 772political party and the background of the person working on the build 773at that time). If host and target are the same, but build is 774different, you are using a cross-compiler to build a native for a 775different system. Some people call this a "host-x-host", "crossed 776native", or "cross-built native". If build and target are the same, 777but host is different, you are using a cross compiler to build a cross 778compiler that produces code for the machine you're building on. This 779is rare, so there is no common way of describing it. There is a 780proposal to call this a "crossback". 781 782 If build and host are the same, the GCC you are building will also be 783used to build the target libraries (like `libstdc++'). If build and 784host are different, you must have already build and installed a cross 785compiler that will be used to build the target libraries (if you 786configured with `--target=foo-bar', this compiler will be called 787`foo-bar-gcc'). 788 789 In the case of target libraries, the machine you're building for is 790the machine you specified with `--target'. So, build is the machine 791you're building on (no change there), host is the machine you're 792building for (the target libraries are built for the target, so host is 793the target you specified), and target doesn't apply (because you're not 794building a compiler, you're building libraries). The configure/make 795process will adjust these variables as needed. It also sets 796`$with_cross_host' to the original `--host' value in case you need it. 797 798 The `libiberty' support library is built up to three times: once for 799the host, once for the target (even if they are the same), and once for 800the build if build and host are different. This allows it to be used 801by all programs which are generated in the course of the build process. 802 803 804File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 805 8066.2 Top Level Source Directory 807============================== 808 809The top level source directory in a GCC distribution contains several 810files and directories that are shared with other software distributions 811such as that of GNU Binutils. It also contains several subdirectories 812that contain parts of GCC and its runtime libraries: 813 814`boehm-gc' 815 The Boehm conservative garbage collector, used as part of the Java 816 runtime library. 817 818`contrib' 819 Contributed scripts that may be found useful in conjunction with 820 GCC. One of these, `contrib/texi2pod.pl', is used to generate man 821 pages from Texinfo manuals as part of the GCC build process. 822 823`fastjar' 824 An implementation of the `jar' command, used with the Java front 825 end. 826 827`gcc' 828 The main sources of GCC itself (except for runtime libraries), 829 including optimizers, support for different target architectures, 830 language front ends, and testsuites. *Note The `gcc' 831 Subdirectory: gcc Directory, for details. 832 833`include' 834 Headers for the `libiberty' library. 835 836`libf2c' 837 The Fortran runtime library. 838 839`libffi' 840 The `libffi' library, used as part of the Java runtime library. 841 842`libiberty' 843 The `libiberty' library, used for portability and for some 844 generally useful data structures and algorithms. *Note 845 Introduction: (libiberty)Top, for more information about this 846 library. 847 848`libjava' 849 The Java runtime library. 850 851`libobjc' 852 The Objective-C runtime library. 853 854`libstdc++-v3' 855 The C++ runtime library. 856 857`maintainer-scripts' 858 Scripts used by the `gccadmin' account on `gcc.gnu.org'. 859 860`zlib' 861 The `zlib' compression library, used by the Java front end and as 862 part of the Java runtime library. 863 864 The build system in the top level directory, including how recursion 865into subdirectories works and how building runtime libraries for 866multilibs is handled, is documented in a separate manual, included with 867GNU Binutils. *Note GNU configure and build system: (configure)Top, 868for details. 869 870 871File: gccint.info, Node: gcc Directory, Next: Testsuites, Prev: Top Level, Up: Source Tree 872 8736.3 The `gcc' Subdirectory 874========================== 875 876The `gcc' directory contains many files that are part of the C sources 877of GCC, other files used as part of the configuration and build 878process, and subdirectories including documentation and a testsuite. 879The files that are sources of GCC are documented in a separate chapter. 880*Note Passes and Files of the Compiler: Passes. 881 882* Menu: 883 884* Subdirectories:: Subdirectories of `gcc'. 885* Configuration:: The configuration process, and the files it uses. 886* Build:: The build system in the `gcc' directory. 887* Makefile:: Targets in `gcc/Makefile'. 888* Library Files:: Library source files and headers under `gcc/'. 889* Headers:: Headers installed by GCC. 890* Documentation:: Building documentation in GCC. 891* Front End:: Anatomy of a language front end. 892* Back End:: Anatomy of a target back end. 893 894 895File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 896 8976.3.1 Subdirectories of `gcc' 898----------------------------- 899 900The `gcc' directory contains the following subdirectories: 901 902`LANGUAGE' 903 Subdirectories for various languages. Directories containing a 904 file `config-lang.in' are language subdirectories. The contents of 905 the subdirectories `cp' (for C++) and `objc' (for Objective-C) are 906 documented in this manual (*note Passes and Files of the Compiler: 907 Passes.); those for other languages are not. *Note Anatomy of a 908 Language Front End: Front End, for details of the files in these 909 directories. 910 911`config' 912 Configuration files for supported architectures and operating 913 systems. *Note Anatomy of a Target Back End: Back End, for 914 details of the files in this directory. 915 916`doc' 917 Texinfo documentation for GCC, together with automatically 918 generated man pages and support for converting the installation 919 manual to HTML. *Note Documentation::. 920 921`fixinc' 922 The support for fixing system headers to work with GCC. See 923 `fixinc/README' for more information. The headers fixed by this 924 mechanism are installed in `LIBSUBDIR/include'. Along with those 925 headers, `README-fixinc' is also installed, as 926 `LIBSUBDIR/include/README'. 927 928`ginclude' 929 System headers installed by GCC, mainly those required by the C 930 standard of freestanding implementations. *Note Headers Installed 931 by GCC: Headers, for details of when these and other headers are 932 installed. 933 934`intl' 935 GNU `libintl', from GNU `gettext', for systems which do not 936 include it in libc. Properly, this directory should be at top 937 level, parallel to the `gcc' directory. 938 939`po' 940 Message catalogs with translations of messages produced by GCC into 941 various languages, `LANGUAGE.po'. This directory also contains 942 `gcc.pot', the template for these message catalogues, `exgettext', 943 a wrapper around `gettext' to extract the messages from the GCC 944 sources and create `gcc.pot', which is run by `make gcc.pot', and 945 `EXCLUDES', a list of files from which messages should not be 946 extracted. 947 948`testsuite' 949 The GCC testsuites (except for those for runtime libraries). 950 *Note Testsuites::. 951 952 953File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 954 9556.3.2 Configuration in the `gcc' Directory 956------------------------------------------ 957 958The `gcc' directory is configured with an Autoconf-generated script 959`configure'. The `configure' script is generated from `configure.ac' 960and `aclocal.m4'. From the files `configure.ac' and `acconfig.h', 961Autoheader generates the file `config.in'. The file `cstamp-h.in' is 962used as a timestamp. 963 964* Menu: 965 966* Config Fragments:: Scripts used by `configure'. 967* System Config:: The `config.build', `config.host', and 968 `config.gcc' files. 969* Configuration Files:: Files created by running `configure'. 970 971 972File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 973 9746.3.2.1 Scripts Used by `configure' 975................................... 976 977`configure' uses some other scripts to help in its work: 978 979 * The standard GNU `config.sub' and `config.guess' files, kept in 980 the top level directory, are used. FIXME: when is the 981 `config.guess' file in the `gcc' directory (that just calls the 982 top level one) used? 983 984 * The file `config.gcc' is used to handle configuration specific to 985 the particular target machine. The file `config.build' is used to 986 handle configuration specific to the particular build machine. 987 The file `config.host' is used to handle configuration specific to 988 the particular host machine. (In general, these should only be 989 used for features that cannot reasonably be tested in Autoconf 990 feature tests.) *Note The `config.build'; `config.host'; and 991 `config.gcc' Files: System Config, for details of the contents of 992 these files. 993 994 * Each language subdirectory has a file `LANGUAGE/config-lang.in' 995 that is used for front-end-specific configuration. *Note The 996 Front End `config-lang.in' File: Front End Config, for details of 997 this file. 998 999 * A helper script `configure.frag' is used as part of creating the 1000 output of `configure'. 1001 1002 1003File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 1004 10056.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files 1006................................................................. 1007 1008The `config.build' file contains specific rules for particular systems 1009which GCC is built on. This should be used as rarely as possible, as 1010the behavior of the build system can always be detected by autoconf. 1011 1012 The `config.host' file contains specific rules for particular systems 1013which GCC will run on. This is rarely needed. 1014 1015 The `config.gcc' file contains specific rules for particular systems 1016which GCC will generate code for. This is usually needed. 1017 1018 Each file has a list of the shell variables it sets, with 1019descriptions, at the top of the file. 1020 1021 FIXME: document the contents of these files, and what variables 1022should be set to control build, host and target configuration. 1023 1024 1025File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 1026 10276.3.2.3 Files Created by `configure' 1028.................................... 1029 1030Here we spell out what files will be set up by `configure' in the `gcc' 1031directory. Some other files are created as temporary files in the 1032configuration process, and are not used in the subsequent build; these 1033are not documented. 1034 1035 * `Makefile' is constructed from `Makefile.in', together with the 1036 host and target fragments (*note Makefile Fragments: Fragments.) 1037 `t-TARGET' and `x-HOST' from `config', if any, and language 1038 Makefile fragments `LANGUAGE/Make-lang.in'. 1039 1040 * `auto-host.h' contains information about the host machine 1041 determined by `configure'. If the host machine is different from 1042 the build machine, then `auto-build.h' is also created, containing 1043 such information about the build machine. 1044 1045 * `config.status' is a script that may be run to recreate the 1046 current configuration. 1047 1048 * `configargs.h' is a header containing details of the arguments 1049 passed to `configure' to configure GCC, and of the thread model 1050 used. 1051 1052 * `cstamp-h' is used as a timestamp. 1053 1054 * `fixinc/Makefile' is constructed from `fixinc/Makefile.in'. 1055 1056 * `gccbug', a script for reporting bugs in GCC, is constructed from 1057 `gccbug.in'. 1058 1059 * `intl/Makefile' is constructed from `intl/Makefile.in'. 1060 1061 * `mklibgcc', a shell script to create a Makefile to build libgcc, 1062 is constructed from `mklibgcc.in'. 1063 1064 * If a language `config-lang.in' file (*note The Front End 1065 `config-lang.in' File: Front End Config.) sets `outputs', then the 1066 files listed in `outputs' there are also generated. 1067 1068 The following configuration headers are created from the Makefile, 1069using `mkconfig.sh', rather than directly by `configure'. `config.h', 1070`bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if 1071any, appropriate to the host, build and target machines respectively, 1072the configuration headers for the target, and some definitions; for the 1073host and build machines, these include the autoconfigured headers 1074generated by `configure'. The other configuration headers are 1075determined by `config.gcc'. They also contain the typedefs for `rtx', 1076`rtvec' and `tree'. 1077 1078 * `config.h', for use in programs that run on the host machine. 1079 1080 * `bconfig.h', for use in programs that run on the build machine. 1081 1082 * `tconfig.h', for use in programs and libraries for the target 1083 machine. 1084 1085 * `tm_p.h', which includes the header `MACHINE-protos.h' that 1086 contains prototypes for functions in the target `.c' file. FIXME: 1087 why is such a separate header necessary? 1088 1089 1090File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 1091 10926.3.3 Build System in the `gcc' Directory 1093----------------------------------------- 1094 1095FIXME: describe the build system, including what is built in what 1096stages. Also list the various source files that are used in the build 1097process but aren't source files of GCC itself and so aren't documented 1098below (*note Passes::). 1099 1100 1101File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 1102 11036.3.4 Makefile Targets 1104---------------------- 1105 1106`all' 1107 This is the default target. Depending on what your 1108 build/host/target configuration is, it coordinates all the things 1109 that need to be built. 1110 1111`doc' 1112 Produce info-formatted documentation and man pages. Essentially it 1113 calls `make man' and `make info'. 1114 1115`dvi' 1116 Produce DVI-formatted documentation. 1117 1118`man' 1119 Generate man pages. 1120 1121`info' 1122 Generate info-formatted pages. 1123 1124`mostlyclean' 1125 Delete the files made while building the compiler. 1126 1127`clean' 1128 That, and all the other files built by `make all'. 1129 1130`distclean' 1131 That, and all the files created by `configure'. 1132 1133`maintainer-clean' 1134 Distclean plus any file that can be generated from other files. 1135 Note that additional tools may be required beyond what is normally 1136 needed to build gcc. 1137 1138`srcextra' 1139 Generates files in the source directory that do not exist in CVS 1140 but should go into a release tarball. One example is 1141 `gcc/c-parse.c' which is generated from the CVS source file 1142 `gcc/c-parse.in'. 1143 1144`srcinfo' 1145`srcman' 1146 Copies the info-formatted and manpage documentation into the source 1147 directory usually for the purpose of generating a release tarball. 1148 1149`install' 1150 Installs gcc. 1151 1152`uninstall' 1153 Deletes installed files. 1154 1155`check' 1156 Run the testsuite. This creates a `testsuite' subdirectory that 1157 has various `.sum' and `.log' files containing the results of the 1158 testing. You can run subsets with, for example, `make check-gcc'. 1159 You can specify specific tests by setting RUNTESTFLAGS to be the 1160 name of the `.exp' file, optionally followed by (for some tests) 1161 an equals and a file wildcard, like: 1162 1163 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 1164 1165 Note that running the testsuite may require additional tools be 1166 installed, such as TCL or dejagnu. 1167 1168`bootstrap' 1169 Builds GCC three times--once with the native compiler, once with 1170 the native-built compiler it just built, and once with the 1171 compiler it built the second time. In theory, the last two should 1172 produce the same results, which `make compare' can check. Each 1173 step of this process is called a "stage", and the results of each 1174 stage N (N = 1...3) are copied to a subdirectory `stageN/'. 1175 1176`bootstrap-lean' 1177 Like `bootstrap', except that the various stages are removed once 1178 they're no longer needed. This saves disk space. 1179 1180`bubblestrap' 1181 This incrementally rebuilds each of the three stages, one at a 1182 time. It does this by "bubbling" the stages up from their 1183 subdirectories (if they had been built previously), rebuilding 1184 them, and copying them back to their subdirectories. This will 1185 allow you to, for example, continue a bootstrap after fixing a bug 1186 which causes the stage2 build to crash. 1187 1188`quickstrap' 1189 Rebuilds the most recently built stage. Since each stage requires 1190 special invocation, using this target means you don't have to keep 1191 track of which stage you're on or what invocation that stage needs. 1192 1193`cleanstrap' 1194 Removed everything (`make clean') and rebuilds (`make bootstrap'). 1195 1196`restrap' 1197 Like `cleanstrap', except that the process starts from the first 1198 stage build, not from scratch. 1199 1200`stageN (N = 1...4)' 1201 For each stage, moves the appropriate files to the `stageN' 1202 subdirectory. 1203 1204`unstageN (N = 1...4)' 1205 Undoes the corresponding `stageN'. 1206 1207`restageN (N = 1...4)' 1208 Undoes the corresponding `stageN' and rebuilds it with the 1209 appropriate flags. 1210 1211`compare' 1212 Compares the results of stages 2 and 3. This ensures that the 1213 compiler is running properly, since it should produce the same 1214 object files regardless of how it itself was compiled. 1215 1216`profiledbootstrap' 1217 Builds a compiler with profiling feedback information. For more 1218 information, see *Note Building with profile feedback: 1219 (gccinstall)Building. This is actually a target in the top-level 1220 directory, which then recurses into the `gcc' subdirectory 1221 multiple times. 1222 1223 1224 1225File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 1226 12276.3.5 Library Source Files and Headers under the `gcc' Directory 1228---------------------------------------------------------------- 1229 1230FIXME: list here, with explanation, all the C source files and headers 1231under the `gcc' directory that aren't built into the GCC executable but 1232rather are part of runtime libraries and object files, such as 1233`crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC: 1234Headers, for more information about the `ginclude' directory. 1235 1236 1237File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 1238 12396.3.6 Headers Installed by GCC 1240------------------------------ 1241 1242In general, GCC expects the system C library to provide most of the 1243headers to be used with it. However, GCC will fix those headers if 1244necessary to make them work with GCC, and will install some headers 1245required of freestanding implementations. These headers are installed 1246in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also 1247installed by GCC; these are not documented here. (FIXME: document them 1248somewhere.) 1249 1250 Several of the headers GCC installs are in the `ginclude' directory. 1251These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', 1252are installed in `LIBSUBDIR/include', unless the target Makefile 1253fragment (*note Target Fragment::) overrides this by setting `USER_H'. 1254 1255 In addition to these headers and those generated by fixing system 1256headers to work with GCC, some other headers may also be installed in 1257`LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this 1258specifies additional headers under `config' to be installed on some 1259systems. 1260 1261 GCC installs its own version of `<float.h>', from `ginclude/float.h'. 1262This is done to cope with command-line options that change the 1263representation of floating point numbers. 1264 1265 GCC also installs its own version of `<limits.h>'; this is generated 1266from `glimits.h', together with `limitx.h' and `limity.h' if the system 1267also has its own version of `<limits.h>'. (GCC provides its own header 1268because it is required of ISO C freestanding implementations, but needs 1269to include the system header from its own header as well because other 1270standards such as POSIX specify additional values to be defined in 1271`<limits.h>'.) The system's `<limits.h>' header is used via 1272`LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if 1273it does not need fixing to work with GCC; if it needs fixing, 1274`syslimits.h' is the fixed copy. 1275 1276 1277File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 1278 12796.3.7 Building Documentation 1280---------------------------- 1281 1282The main GCC documentation is in the form of manuals in Texinfo format. 1283These are installed in Info format, and DVI versions may be generated 1284by `make dvi'. In addition, some man pages are generated from the 1285Texinfo manuals, there are some other text files with miscellaneous 1286documentation, and runtime libraries have their own documentation 1287outside the `gcc' directory. FIXME: document the documentation for 1288runtime libraries somewhere. 1289 1290* Menu: 1291 1292* Texinfo Manuals:: GCC manuals in Texinfo format. 1293* Man Page Generation:: Generating man pages from Texinfo manuals. 1294* Miscellaneous Docs:: Miscellaneous text files with documentation. 1295 1296 1297File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 1298 12996.3.7.1 Texinfo Manuals 1300....................... 1301 1302The manuals for GCC as a whole, and the C and C++ front ends, are in 1303files `doc/*.texi'. Other front ends have their own manuals in files 1304`LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided 1305which may be included in multiple manuals; the following files are in 1306`doc/include': 1307 1308`fdl.texi' 1309 The GNU Free Documentation License. 1310 1311`funding.texi' 1312 The section "Funding Free Software". 1313 1314`gcc-common.texi' 1315 Common definitions for manuals. 1316 1317`gpl.texi' 1318 The GNU General Public License. 1319 1320`texinfo.tex' 1321 A copy of `texinfo.tex' known to work with the GCC manuals. 1322 1323 DVI formatted manuals are generated by `make dvi', which uses 1324`texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). Info manuals are 1325generated by `make info' (which is run as part of a bootstrap); this 1326generates the manuals in the source directory, using `makeinfo' via the 1327Makefile macro `$(MAKEINFO)', and they are included in release 1328distributions. 1329 1330 Manuals are also provided on the GCC web site, in both HTML and 1331PostScript forms. This is done via the script 1332`maintainer-scripts/update_web_docs'. Each manual to be provided 1333online must be listed in the definition of `MANUALS' in that file; a 1334file `NAME.texi' must only appear once in the source tree, and the 1335output manual must have the same name as the source file. (However, 1336other Texinfo files, included in manuals but not themselves the root 1337files of manuals, may have names that appear more than once in the 1338source tree.) The manual file `NAME.texi' should only include other 1339files in its own directory or in `doc/include'. HTML manuals will be 1340generated by `makeinfo --html' and PostScript manuals by `texi2dvi' and 1341`dvips'. All Texinfo files that are parts of manuals must be checked 1342into CVS, even if they are generated files, for the generation of 1343online manuals to work. 1344 1345 The installation manual, `doc/install.texi', is also provided on the 1346GCC web site. The HTML version is generated by the script 1347`doc/install.texi2html'. 1348 1349 1350File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 1351 13526.3.7.2 Man Page Generation 1353........................... 1354 1355Because of user demand, in addition to full Texinfo manuals, man pages 1356are provided which contain extracts from those manuals. These man 1357pages are generated from the Texinfo manuals using 1358`contrib/texi2pod.pl' and `pod2man'. (The man page for `g++', 1359`cp/g++.1', just contains a `.so' reference to `gcc.1', but all the 1360other man pages are generated from Texinfo manuals.) 1361 1362 Because many systems may not have the necessary tools installed to 1363generate the man pages, they are only generated if the `configure' 1364script detects that recent enough tools are installed, and the 1365Makefiles allow generating man pages to fail without aborting the 1366build. Man pages are also included in release distributions. They are 1367generated in the source directory. 1368 1369 Magic comments in Texinfo files starting `@c man' control what parts 1370of a Texinfo file go into a man page. Only a subset of Texinfo is 1371supported by `texi2pod.pl', and it may be necessary to add support for 1372more Texinfo features to this script when generating new man pages. To 1373improve the man page output, some special Texinfo macros are provided 1374in `doc/include/gcc-common.texi' which `texi2pod.pl' understands: 1375 1376`@gcctabopt' 1377 Use in the form `@table @gcctabopt' for tables of options, where 1378 for printed output the effect of `@code' is better than that of 1379 `@option' but for man page output a different effect is wanted. 1380 1381`@gccoptlist' 1382 Use for summary lists of options in manuals. 1383 1384`@gol' 1385 Use at the end of each line inside `@gccoptlist'. This is 1386 necessary to avoid problems with differences in how the 1387 `@gccoptlist' macro is handled by different Texinfo formatters. 1388 1389 FIXME: describe the `texi2pod.pl' input language and magic comments 1390in more detail. 1391 1392 1393File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 1394 13956.3.7.3 Miscellaneous Documentation 1396................................... 1397 1398In addition to the formal documentation that is installed by GCC, there 1399are several other text files with miscellaneous documentation: 1400 1401`ABOUT-GCC-NLS' 1402 Notes on GCC's Native Language Support. FIXME: this should be 1403 part of this manual rather than a separate file. 1404 1405`ABOUT-NLS' 1406 Notes on the Free Translation Project. 1407 1408`COPYING' 1409 The GNU General Public License. 1410 1411`COPYING.LIB' 1412 The GNU Lesser General Public License. 1413 1414`*ChangeLog*' 1415`*/ChangeLog*' 1416 Change log files for various parts of GCC. 1417 1418`LANGUAGES' 1419 Details of a few changes to the GCC front-end interface. FIXME: 1420 the information in this file should be part of general 1421 documentation of the front-end interface in this manual. 1422 1423`ONEWS' 1424 Information about new features in old versions of GCC. (For recent 1425 versions, the information is on the GCC web site.) 1426 1427`README.Portability' 1428 Information about portability issues when writing code in GCC. 1429 FIXME: why isn't this part of this manual or of the GCC Coding 1430 Conventions? 1431 1432`SERVICE' 1433 A pointer to the GNU Service Directory. 1434 1435 FIXME: document such files in subdirectories, at least `config', 1436`cp', `objc', `testsuite'. 1437 1438 1439File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 1440 14416.3.8 Anatomy of a Language Front End 1442------------------------------------- 1443 1444A front end for a language in GCC has the following parts: 1445 1446 * A directory `LANGUAGE' under `gcc' containing source files for 1447 that front end. *Note The Front End `LANGUAGE' Directory: Front 1448 End Directory, for details. 1449 1450 * A mention of the language in the list of supported languages in 1451 `gcc/doc/install.texi'. 1452 1453 * A mention of the name under which the language's runtime library is 1454 recognized by `--enable-shared=PACKAGE' in the documentation of 1455 that option in `gcc/doc/install.texi'. 1456 1457 * A mention of any special prerequisites for building the front end 1458 in the documentation of prerequisites in `gcc/doc/install.texi'. 1459 1460 * Details of contributors to that front end in 1461 `gcc/doc/contrib.texi'. If the details are in that front end's 1462 own manual then there should be a link to that manual's list in 1463 `contrib.texi'. 1464 1465 * Information about support for that language in 1466 `gcc/doc/frontends.texi'. 1467 1468 * Information about standards for that language, and the front end's 1469 support for them, in `gcc/doc/standards.texi'. This may be a link 1470 to such information in the front end's own manual. 1471 1472 * Details of source file suffixes for that language and `-x LANG' 1473 options supported, in `gcc/doc/invoke.texi'. 1474 1475 * Entries in `default_compilers' in `gcc.c' for source file suffixes 1476 for that language. 1477 1478 * Preferably testsuites, which may be under `gcc/testsuite' or 1479 runtime library directories. FIXME: document somewhere how to 1480 write testsuite harnesses. 1481 1482 * Probably a runtime library for the language, outside the `gcc' 1483 directory. FIXME: document this further. 1484 1485 * Details of the directories of any runtime libraries in 1486 `gcc/doc/sourcebuild.texi'. 1487 1488 If the front end is added to the official GCC CVS repository, the 1489following are also necessary: 1490 1491 * At least one Bugzilla component for bugs in that front end and 1492 runtime libraries. This category needs to be mentioned in 1493 `gcc/gccbug.in', as well as being added to the Bugzilla database. 1494 1495 * Normally, one or more maintainers of that front end listed in 1496 `MAINTAINERS'. 1497 1498 * Mentions on the GCC web site in `index.html' and `frontends.html', 1499 with any relevant links on `readings.html'. (Front ends that are 1500 not an official part of GCC may also be listed on 1501 `frontends.html', with relevant links.) 1502 1503 * A news item on `index.html', and possibly an announcement on the 1504 <gcc-announce@gcc.gnu.org> mailing list. 1505 1506 * The front end's manuals should be mentioned in 1507 `maintainer-scripts/update_web_docs' (*note Texinfo Manuals::) and 1508 the online manuals should be linked to from 1509 `onlinedocs/index.html'. 1510 1511 * Any old releases or CVS repositories of the front end, before its 1512 inclusion in GCC, should be made available on the GCC FTP site 1513 `ftp://gcc.gnu.org/pub/gcc/old-releases/'. 1514 1515 * The release and snapshot script `maintainer-scripts/gcc_release' 1516 should be updated to generate appropriate tarballs for this front 1517 end. The associated `maintainer-scripts/snapshot-README' and 1518 `maintainer-scripts/snapshot-index.html' files should be updated 1519 to list the tarballs and diffs for this front end. 1520 1521 * If this front end includes its own version files that include the 1522 current date, `maintainer-scripts/update_version' should be 1523 updated accordingly. 1524 1525 * `CVSROOT/modules' in the GCC CVS repository should be updated. 1526 1527* Menu: 1528 1529* Front End Directory:: The front end `LANGUAGE' directory. 1530* Front End Config:: The front end `config-lang.in' file. 1531 1532 1533File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 1534 15356.3.8.1 The Front End `LANGUAGE' Directory 1536.......................................... 1537 1538A front end `LANGUAGE' directory contains the source files of that 1539front end (but not of any runtime libraries, which should be outside 1540the `gcc' directory). This includes documentation, and possibly some 1541subsidiary programs build alongside the front end. Certain files are 1542special and other parts of the compiler depend on their names: 1543 1544`config-lang.in' 1545 This file is required in all language subdirectories. *Note The 1546 Front End `config-lang.in' File: Front End Config, for details of 1547 its contents 1548 1549`Make-lang.in' 1550 This file is required in all language subdirectories. It contains 1551 targets `LANG.HOOK' (where `LANG' is the setting of `language' in 1552 `config-lang.in') for the following values of `HOOK', and any 1553 other Makefile rules required to build those targets (which may if 1554 necessary use other Makefiles specified in `outputs' in 1555 `config-lang.in', although this is deprecated). Some hooks are 1556 defined by using a double-colon rule for `HOOK', rather than by 1557 using a target of form `LANG.HOOK'. These hooks are called 1558 "double-colon hooks" below. It also adds any testsuite targets 1559 that can use the standard rule in `gcc/Makefile.in' to the variable 1560 `lang_checks'. 1561 1562 `all.build' 1563 `all.cross' 1564 `start.encap' 1565 `rest.encap' 1566 FIXME: exactly what goes in each of these targets? 1567 1568 `tags' 1569 Build an `etags' `TAGS' file in the language subdirectory in 1570 the source tree. 1571 1572 `info' 1573 Build info documentation for the front end, in the build 1574 directory. This target is only called by `make bootstrap' if 1575 a suitable version of `makeinfo' is available, so does not 1576 need to check for this, and should fail if an error occurs. 1577 1578 `dvi' 1579 Build DVI documentation for the front end, in the build 1580 directory. This should be done using `$(TEXI2DVI)', with 1581 appropriate `-I' arguments pointing to directories of 1582 included files. This hook is a double-colon hook. 1583 1584 `man' 1585 Build generated man pages for the front end from Texinfo 1586 manuals (*note Man Page Generation::), in the build 1587 directory. This target is only called if the necessary tools 1588 are available, but should ignore errors so as not to stop the 1589 build if errors occur; man pages are optional and the tools 1590 involved may be installed in a broken way. 1591 1592 `install-normal' 1593 FIXME: what is this target for? 1594 1595 `install-common' 1596 Install everything that is part of the front end, apart from 1597 the compiler executables listed in `compilers' in 1598 `config-lang.in'. 1599 1600 `install-info' 1601 Install info documentation for the front end, if it is 1602 present in the source directory. This target should have 1603 dependencies on info files that should be installed. This 1604 hook is a double-colon hook. 1605 1606 `install-man' 1607 Install man pages for the front end. This target should 1608 ignore errors. 1609 1610 `srcextra' 1611 Copies its dependencies into the source directory. This 1612 generally should be used for generated files such as 1613 `gcc/c-parse.c' which are not present in CVS, but should be 1614 included in any release tarballs. This target will be 1615 executed during a bootstrap if 1616 `--enable-generated-files-in-srcdir' was specified as a 1617 `configure' option. 1618 1619 `srcinfo' 1620 `srcman' 1621 Copies its dependencies into the source directory. These 1622 targets will be executed during a bootstrap if 1623 `--enable-generated-files-in-srcdir' was specified as a 1624 `configure' option. 1625 1626 `uninstall' 1627 Uninstall files installed by installing the compiler. This is 1628 currently documented not to be supported, so the hook need 1629 not do anything. 1630 1631 `mostlyclean' 1632 `clean' 1633 `distclean' 1634 `maintainer-clean' 1635 The language parts of the standard GNU `*clean' targets. 1636 *Note Standard Targets for Users: (standards)Standard 1637 Targets, for details of the standard targets. For GCC, 1638 `maintainer-clean' should delete all generated files in the 1639 source directory that are not checked into CVS, but should 1640 not delete anything checked into CVS. 1641 1642 `stage1' 1643 `stage2' 1644 `stage3' 1645 `stage4' 1646 `stageprofile' 1647 `stagefeedback' 1648 Move to the stage directory files not included in 1649 `stagestuff' in `config-lang.in' or otherwise moved by the 1650 main `Makefile'. 1651 1652`lang.opt' 1653 This file registers the set of switches that the front end accepts 1654 on the command line, and their -help text. The file format is 1655 documented in the file `c.opt'. These files are processed by the 1656 script `opts.sh'. 1657 1658`lang-specs.h' 1659 This file provides entries for `default_compilers' in `gcc.c' 1660 which override the default of giving an error that a compiler for 1661 that language is not installed. 1662 1663`LANGUAGE-tree.def' 1664 This file, which need not exist, defines any language-specific tree 1665 codes. 1666 1667 1668File: gccint.info, Node: Front End Config, Prev: Front End Directory, Up: Front End 1669 16706.3.8.2 The Front End `config-lang.in' File 1671........................................... 1672 1673Each language subdirectory contains a `config-lang.in' file. In 1674addition the main directory contains `c-config-lang.in', which contains 1675limited information for the C language. This file is a shell script 1676that may define some variables describing the language: 1677 1678`language' 1679 This definition must be present, and gives the name of the language 1680 for some purposes such as arguments to `--enable-languages'. 1681 1682`lang_requires' 1683 If defined, this variable lists (space-separated) language front 1684 ends other than C that this front end requires to be enabled (with 1685 the names given being their `language' settings). For example, the 1686 Java front end depends on the C++ front end, so sets 1687 `lang_requires=c++'. 1688 1689`target_libs' 1690 If defined, this variable lists (space-separated) targets in the 1691 top level `Makefile' to build the runtime libraries for this 1692 language, such as `target-libobjc'. 1693 1694`lang_dirs' 1695 If defined, this variable lists (space-separated) top level 1696 directories (parallel to `gcc'), apart from the runtime libraries, 1697 that should not be configured if this front end is not built. 1698 1699`build_by_default' 1700 If defined to `no', this language front end is not built unless 1701 enabled in a `--enable-languages' argument. Otherwise, front ends 1702 are built by default, subject to any special logic in 1703 `configure.ac' (as is present to disable the Ada front end if the 1704 Ada compiler is not already installed). 1705 1706`boot_language' 1707 If defined to `yes', this front end is built in stage 1 of the 1708 bootstrap. This is only relevant to front ends written in their 1709 own languages. 1710 1711`compilers' 1712 If defined, a space-separated list of compiler executables that 1713 will be run by the driver. The names here will each end with 1714 `\$(exeext)'. 1715 1716`stagestuff' 1717 If defined, a space-separated list of files that should be moved to 1718 the `stageN' directories in each stage of bootstrap. 1719 1720`outputs' 1721 If defined, a space-separated list of files that should be 1722 generated by `configure' substituting values in them. This 1723 mechanism can be used to create a file `LANGUAGE/Makefile' from 1724 `LANGUAGE/Makefile.in', but this is deprecated, building 1725 everything from the single `gcc/Makefile' is preferred. 1726 1727`gtfiles' 1728 If defined, a space-separated list of files that should be scanned 1729 by gengtype.c to generate the garbage collection tables and 1730 routines for this language. This excludes the files that are 1731 common to all front ends. *Note Type Information::. 1732 1733 1734 1735File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 1736 17376.3.9 Anatomy of a Target Back End 1738---------------------------------- 1739 1740A back end for a target architecture in GCC has the following parts: 1741 1742 * A directory `MACHINE' under `gcc/config', containing a machine 1743 description `MACHINE.md' file (*note Machine Descriptions: Machine 1744 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a 1745 source file `MACHINE.c' (*note Target Description Macros and 1746 Functions: Target Macros.), possibly a target Makefile fragment 1747 `t-MACHINE' (*note The Target Makefile Fragment: Target 1748 Fragment.), and maybe some other files. The names of these files 1749 may be changed from the defaults given by explicit specifications 1750 in `config.gcc'. 1751 1752 * If necessary, a file `MACHINE-modes.def' in the `MACHINE' 1753 directory, containing additional machine modes to represent 1754 condition codes. *Note Condition Code::, for further details. 1755 1756 * Entries in `config.gcc' (*note The `config.gcc' File: System 1757 Config.) for the systems with this target architecture. 1758 1759 * Documentation in `gcc/doc/invoke.texi' for any command-line 1760 options supported by this target (*note Run-time Target 1761 Specification: Run-time Target.). This means both entries in the 1762 summary table of options and details of the individual options. 1763 1764 * Documentation in `gcc/doc/extend.texi' for any target-specific 1765 attributes supported (*note Defining target-specific uses of 1766 `__attribute__': Target Attributes.), including where the same 1767 attribute is already supported on some targets, which are 1768 enumerated in the manual. 1769 1770 * Documentation in `gcc/doc/extend.texi' for any target-specific 1771 pragmas supported. 1772 1773 * Documentation in `gcc/doc/extend.texi' of any target-specific 1774 built-in functions supported. 1775 1776 * Documentation in `gcc/doc/md.texi' of any target-specific 1777 constraint letters (*note Constraints for Particular Machines: 1778 Machine Constraints.). 1779 1780 * A note in `gcc/doc/contrib.texi' under the person or people who 1781 contributed the target support. 1782 1783 * Entries in `gcc/doc/install.texi' for all target triplets 1784 supported with this target architecture, giving details of any 1785 special notes about installation for this target, or saying that 1786 there are no special notes if there are none. 1787 1788 * Possibly other support outside the `gcc' directory for runtime 1789 libraries. FIXME: reference docs for this. The libstdc++ porting 1790 manual needs to be installed as info for this to work, or to be a 1791 chapter of this manual. 1792 1793 If the back end is added to the official GCC CVS repository, the 1794following are also necessary: 1795 1796 * An entry for the target architecture in `readings.html' on the GCC 1797 web site, with any relevant links. 1798 1799 * Details of the properties of the back end and target architecture 1800 in `backends.html' on the GCC web site. 1801 1802 * A news item about the contribution of support for that target 1803 architecture, in `index.html' on the GCC web site. 1804 1805 * Normally, one or more maintainers of that target listed in 1806 `MAINTAINERS'. Some existing architectures may be unmaintained, 1807 but it would be unusual to add support for a target that does not 1808 have a maintainer when support is added. 1809 1810 1811File: gccint.info, Node: Testsuites, Prev: gcc Directory, Up: Source Tree 1812 18136.4 Testsuites 1814============== 1815 1816GCC contains several testsuites to help maintain compiler quality. 1817Most of the runtime libraries and language front ends in GCC have 1818testsuites. Currently only the C language testsuites are documented 1819here; FIXME: document the others. 1820 1821* Menu: 1822 1823* Test Idioms:: Idioms used in testsuite code. 1824* Ada Tests:: The Ada language testsuites. 1825* C Tests:: The C language testsuites. 1826* libgcj Tests:: The Java library testsuites. 1827* gcov Testing:: Support for testing gcov. 1828* profopt Testing:: Support for testing profile-directed optimizations. 1829* compat Testing:: Support for testing binary compatibility. 1830 1831 1832File: gccint.info, Node: Test Idioms, Next: Ada Tests, Up: Testsuites 1833 18346.4.1 Idioms Used in Testsuite Code 1835----------------------------------- 1836 1837In general C testcases have a trailing `-N.c', starting with `-1.c', in 1838case other testcases with similar names are added later. If the test 1839is a test of some well-defined feature, it should have a name referring 1840to that feature such as `FEATURE-1.c'. If it does not test a 1841well-defined feature but just happens to exercise a bug somewhere in 1842the compiler, and a bug report has been filed for this bug in the GCC 1843bug database, `prBUG-NUMBER-1.c' is the appropriate form of name. 1844Otherwise (for miscellaneous bugs not filed in the GCC bug database), 1845and previously more generally, test cases are named after the date on 1846which they were added. This allows people to tell at a glance whether 1847a test failure is because of a recently found bug that has not yet been 1848fixed, or whether it may be a regression, but does not give any other 1849information about the bug or where discussion of it may be found. Some 1850other language testsuites follow similar conventions. 1851 1852 Test cases should use `abort ()' to indicate failure and `exit (0)' 1853for success; on some targets these may be redefined to indicate failure 1854and success in other ways. 1855 1856 In the `gcc.dg' testsuite, it is often necessary to test that an 1857error is indeed a hard error and not just a warning--for example, where 1858it is a constraint violation in the C standard, which must become an 1859error with `-pedantic-errors'. The following idiom, where the first 1860line shown is line LINE of the file and the line that generates the 1861error, is used for this: 1862 1863 /* { dg-bogus "warning" "warning in place of error" } */ 1864 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 1865 1866 It may be necessary to check that an expression is an integer 1867constant expression and has a certain value. To check that `E' has 1868value `V', an idiom similar to the following is used: 1869 1870 char x[((E) == (V) ? 1 : -1)]; 1871 1872 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions 1873about the types of expressions. See, for example, 1874`gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 1875rules for the types of conditional expressions in the C standard; see, 1876for example, `gcc.dg/c99-intconst-1.c'. 1877 1878 It is useful to be able to test that optimizations are being made 1879properly. This cannot be done in all cases, but it can be done where 1880the optimization will lead to code being optimized away (for example, 1881where flow analysis or alias analysis should show that certain code 1882cannot be called) or to functions not being called because they have 1883been expanded as built-in functions. Such tests go in 1884`gcc.c-torture/execute'. Where code should be optimized away, a call 1885to a nonexistent function such as `link_failure ()' may be inserted; a 1886definition 1887 1888 #ifndef __OPTIMIZE__ 1889 void 1890 link_failure (void) 1891 { 1892 abort (); 1893 } 1894 #endif 1895 1896will also be needed so that linking still succeeds when the test is run 1897without optimization. When all calls to a built-in function should 1898have been optimized and no calls to the non-built-in version of the 1899function should remain, that function may be defined as `static' to 1900call `abort ()' (although redeclaring a function as static may not work 1901on all targets). 1902 1903 All testcases must be portable. Target-specific testcases must have 1904appropriate code to avoid causing failures on unsupported systems; 1905unfortunately, the mechanisms for this differ by directory. 1906 1907 FIXME: discuss non-C testsuites here. 1908 1909 1910File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Idioms, Up: Testsuites 1911 19126.4.2 Ada Language Testsuites 1913----------------------------- 1914 1915The Ada testsuite includes executable tests from the ACATS 2.5 1916testsuite, publicly available at 1917`http://www.adaic.org/compilers/acats/2.5' 1918 1919 These tests are integrated in the GCC testsuite in the 1920`gcc/testsuite/ada/acats' directory, and enabled automatically when 1921running `make check', assuming the Ada language has been enabled when 1922configuring GCC. 1923 1924 You can also run the Ada testsuite independently, using `make 1925check-ada', or run a subset of the tests by specifying which chapter to 1926run, e.g: 1927 1928 $ make check-ada CHAPTERS="c3 c9" 1929 1930 The tests are organized by directory, each directory corresponding to 1931a chapter of the Ada Reference Manual. So for example, c9 corresponds 1932to chapter 9, which deals with tasking features of the language. 1933 1934 There is also an extra chapter called `gcc' containing a template for 1935creating new executable tests. 1936 1937 The tests are run using two 'sh' scripts: run_acats and run_all.sh 1938To run the tests using a simulator or a cross target, see the small 1939customization section at the top of run_all.sh 1940 1941 These tests are run using the build tree: they can be run without 1942doing a `make install'. 1943 1944 1945File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 1946 19476.4.3 C Language Testsuites 1948--------------------------- 1949 1950GCC contains the following C language testsuites, in the 1951`gcc/testsuite' directory: 1952 1953`gcc.dg' 1954 This contains tests of particular features of the C compiler, 1955 using the more modern `dg' harness. Correctness tests for various 1956 compiler features should go here if possible. 1957 1958 Magic comments determine whether the file is preprocessed, 1959 compiled, linked or run. In these tests, error and warning 1960 message texts are compared against expected texts or regular 1961 expressions given in comments. These tests are run with the 1962 options `-ansi -pedantic' unless other options are given in the 1963 test. Except as noted below they are not run with multiple 1964 optimization options. 1965 1966`gcc.dg/compat' 1967 This subdirectory contains tests for binary compatibility using 1968 `compat.exp', which in turn uses the language-independent support 1969 (*note Support for testing binary compatibility: compat Testing.). 1970 1971`gcc.dg/cpp' 1972 This subdirectory contains tests of the preprocessor. 1973 1974`gcc.dg/debug' 1975 This subdirectory contains tests for debug formats. Tests in this 1976 subdirectory are run for each debug format that the compiler 1977 supports. 1978 1979`gcc.dg/format' 1980 This subdirectory contains tests of the `-Wformat' format 1981 checking. Tests in this directory are run with and without 1982 `-DWIDE'. 1983 1984`gcc.dg/noncompile' 1985 This subdirectory contains tests of code that should not compile 1986 and does not need any special compilation options. They are run 1987 with multiple optimization options, since sometimes invalid code 1988 crashes the compiler with optimization. 1989 1990`gcc.dg/special' 1991 FIXME: describe this. 1992 1993`gcc.c-torture' 1994 This contains particular code fragments which have historically 1995 broken easily. These tests are run with multiple optimization 1996 options, so tests for features which only break at some 1997 optimization levels belong here. This also contains tests to 1998 check that certain optimizations occur. It might be worthwhile to 1999 separate the correctness tests cleanly from the code quality 2000 tests, but it hasn't been done yet. 2001 2002`gcc.c-torture/compat' 2003 FIXME: describe this. 2004 2005 This directory should probably not be used for new tests. 2006 2007`gcc.c-torture/compile' 2008 This testsuite contains test cases that should compile, but do not 2009 need to link or run. These test cases are compiled with several 2010 different combinations of optimization options. All warnings are 2011 disabled for these test cases, so this directory is not suitable if 2012 you wish to test for the presence or absence of compiler warnings. 2013 While special options can be set, and tests disabled on specific 2014 platforms, by the use of `.x' files, mostly these test cases 2015 should not contain platform dependencies. FIXME: discuss how 2016 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used. 2017 2018`gcc.c-torture/execute' 2019 This testsuite contains test cases that should compile, link and 2020 run; otherwise the same comments as for `gcc.c-torture/compile' 2021 apply. 2022 2023`gcc.c-torture/execute/ieee' 2024 This contains tests which are specific to IEEE floating point. 2025 2026`gcc.c-torture/unsorted' 2027 FIXME: describe this. 2028 2029 This directory should probably not be used for new tests. 2030 2031`gcc.c-torture/misc-tests' 2032 This directory contains C tests that require special handling. 2033 Some of these tests have individual expect files, and others share 2034 special-purpose expect files: 2035 2036 ``bprob*.c'' 2037 Test `-fbranch-probabilities' using `bprob.exp', which in 2038 turn uses the generic, language-independent framework (*note 2039 Support for testing profile-directed optimizations: profopt 2040 Testing.). 2041 2042 ``dg-*.c'' 2043 Test the testsuite itself using `dg-test.exp'. 2044 2045 ``gcov*.c'' 2046 Test `gcov' output using `gcov.exp', which in turn uses the 2047 language-independent support (*note Support for testing gcov: 2048 gcov Testing.). 2049 2050 ``i386-pf-*.c'' 2051 Test i386-specific support for data prefetch using 2052 `i386-prefetch.exp'. 2053 2054 2055 FIXME: merge in `testsuite/README.gcc' and discuss the format of 2056test cases and magic comments more. 2057 2058 2059File: gccint.info, Node: libgcj Tests, Next: gcov Testing, Prev: C Tests, Up: Testsuites 2060 20616.4.4 The Java library testsuites. 2062---------------------------------- 2063 2064Runtime tests are executed via `make check' in the 2065`TARGET/libjava/testsuite' directory in the build tree. Additional 2066runtime tests can be checked into this testsuite. 2067 2068 Regression testing of the core packages in libgcj is also covered by 2069the Mauve testsuite. The Mauve Project develops tests for the Java 2070Class Libraries. These tests are run as part of libgcj testing by 2071placing the Mauve tree within the libjava testsuite sources at 2072`libjava/testsuite/libjava.mauve/mauve', or by specifying the location 2073of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'. 2074 2075 To detect regressions, a mechanism in `mauve.exp' compares the 2076failures for a test run against the list of expected failures in 2077`libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 2078Update this file when adding new failing tests to Mauve, or when fixing 2079bugs in libgcj that had caused Mauve test failures. 2080 2081 The Jacks project provides a testsuite for Java compilers that can 2082be used to test changes that affect the GCJ front end. This testsuite 2083is run as part of Java testing by placing the Jacks tree within the the 2084libjava testsuite sources at `libjava/testsuite/libjava.jacks/jacks'. 2085 2086 We encourage developers to contribute test cases to Mauve and Jacks. 2087 2088 2089File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: libgcj Tests, Up: Testsuites 2090 20916.4.5 Support for testing `gcov' 2092-------------------------------- 2093 2094Language-independent support for testing `gcov', and for checking that 2095branch profiling produces expected values, is provided by the expect 2096file `gcov.exp'. `gcov' tests also rely on procedures in `gcc.dg.exp' 2097to compile and run the test program. A typical `gcov' test contains 2098the following DejaGNU commands within comments: 2099 2100 { dg-options "-fprofile-arcs -ftest-coverage" } 2101 { dg-do run { target native } } 2102 { dg-final { run-gcov sourcefile } } 2103 2104 Checks of `gcov' output can include line counts, branch percentages, 2105and call return percentages. All of these checks are requested via 2106commands that appear in comments in the test's source file. Commands 2107to check line counts are processed by default. Commands to check 2108branch percentages and call return percentages are processed if the 2109`run-gcov' command has arguments `branches' or `calls', respectively. 2110For example, the following specifies checking both, as well as passing 2111`-b' to `gcov': 2112 2113 { dg-final { run-gcov branches calls { -b sourcefile } } } 2114 2115 A line count command appears within a comment on the source line 2116that is expected to get the specified count and has the form 2117`count(CNT)'. A test should only check line counts for lines that will 2118get the same count for any architecture. 2119 2120 Commands to check branch percentages (`branch') and call return 2121percentages (`returns') are very similar to each other. A beginning 2122command appears on or before the first of a range of lines that will 2123report the percentage, and the ending command follows that range of 2124lines. The beginning command can include a list of percentages, all of 2125which are expected to be found within the range. A range is terminated 2126by the next command of the same kind. A command `branch(end)' or 2127`returns(end)' marks the end of a range without starting a new one. 2128For example: 2129 2130 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 2131 /* branch(end) */ 2132 foo (i, j); 2133 2134 For a call return percentage, the value specified is the percentage 2135of calls reported to return. For a branch percentage, the value is 2136either the expected percentage or 100 minus that value, since the 2137direction of a branch can differ depending on the target or the 2138optimization level. 2139 2140 Not all branches and calls need to be checked. A test should not 2141check for branches that might be optimized away or replaced with 2142predicated instructions. Don't check for calls inserted by the 2143compiler or ones that might be inlined or optimized away. 2144 2145 A single test can check for combinations of line counts, branch 2146percentages, and call return percentages. The command to check a line 2147count must appear on the line that will report that count, but commands 2148to check branch percentages and call return percentages can bracket the 2149lines that report them. 2150 2151 2152File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 2153 21546.4.6 Support for testing profile-directed optimizations 2155-------------------------------------------------------- 2156 2157The file `profopt.exp' provides language-independent support for 2158checking correct execution of a test built with profile-directed 2159optimization. This testing requires that a test program be built and 2160executed twice. The first time it is compiled to generate profile 2161data, and the second time it is compiled to use the data that was 2162generated during the first execution. The second execution is to 2163verify that the test produces the expected results. 2164 2165 To check that the optimization actually generated better code, a 2166test can be built and run a third time with normal optimizations to 2167verify that the performance is better with the profile-directed 2168optimizations. `profopt.exp' has the beginnings of this kind of 2169support. 2170 2171 `profopt.exp' provides generic support for profile-directed 2172optimizations. Each set of tests that uses it provides information 2173about a specific optimization: 2174 2175`tool' 2176 tool being tested, e.g., `gcc' 2177 2178`profile_option' 2179 options used to generate profile data 2180 2181`feedback_option' 2182 options used to optimize using that profile data 2183 2184`prof_ext' 2185 suffix of profile data files 2186 2187`PROFOPT_OPTIONS' 2188 list of options with which to run each test, similar to the lists 2189 for torture tests 2190 2191 2192File: gccint.info, Node: compat Testing, Prev: profopt Testing, Up: Testsuites 2193 21946.4.7 Support for testing binary compatibility 2195---------------------------------------------- 2196 2197The file `compat.exp' provides language-independent support for binary 2198compatibility testing. It supports testing interoperability of two 2199compilers that follow the same ABI, or of multiple sets of compiler 2200options that should not affect binary compatibility. It is intended to 2201be used for testsuites that complement ABI testsuites. 2202 2203 A test supported by this framework has three parts, each in a 2204separate source file: a main program and two pieces that interact with 2205each other to split up the functionality being tested. 2206 2207`TESTNAME_main.SUFFIX' 2208 Contains the main program, which calls a function in file 2209 `TESTNAME_x.SUFFIX'. 2210 2211`TESTNAME_x.SUFFIX' 2212 Contains at least one call to a function in `TESTNAME_y.SUFFIX'. 2213 2214`TESTNAME_y.SUFFIX' 2215 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'. 2216 2217 Within each test, the main program and one functional piece are 2218compiled by the GCC under test. The other piece can be compiled by an 2219alternate compiler. If no alternate compiler is specified, then all 2220three source files are all compiled by the GCC under test. It's also 2221possible to specify a pair of lists of compiler options, one list for 2222each compiler, so that each test will be compiled with each pair of 2223options. 2224 2225 `compat.exp' defines default pairs of compiler options. These can 2226be overridden by defining the environment variable `COMPAT_OPTIONS' as: 2227 2228 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 2229 ...[list {TSTN} {ALTN}]]" 2230 2231 where TSTI and ALTI are lists of options, with TSTI used by the 2232compiler under test and ALTI used by the alternate compiler. For 2233example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 2234the test is first built with `-g -O0' by the compiler under test and 2235with `-O3' by the alternate compiler. The test is built a second time 2236using `-fpic' by the compiler under test and `-fPIC -O2' by the 2237alternate compiler. 2238 2239 An alternate compiler is specified by defining an environment 2240variable; for C++ define `ALT_CXX_UNDER_TEST' to be the full pathname 2241of an installed compiler. That will be written to the `site.exp' file 2242used by DejaGNU. The default is to build each test with the compiler 2243under test using the first of each pair of compiler options from 2244`COMPAT_OPTIONS'. When `ALT_CXX_UNDER_TEST' is `same', each test is 2245built using the compiler under test but with combinations of the 2246options from `COMPAT_OPTIONS'. 2247 2248 To run only the C++ compatibility suite using the compiler under test 2249and another version of GCC using specific compiler options, do the 2250following from `OBJDIR/gcc': 2251 2252 rm site.exp 2253 make -k \ 2254 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 2255 COMPAT_OPTIONS="lists as shown above" \ 2256 check-c++ \ 2257 RUNTESTFLAGS="compat.exp" 2258 2259 A test that fails when the source files are compiled with different 2260compilers, but passes when the files are compiled with the same 2261compiler, demonstrates incompatibility of the generated code or runtime 2262support. A test that fails for the alternate compiler but passes for 2263the compiler under test probably tests for a bug that was fixed in the 2264compiler under test but is present in the alternate compiler. 2265 2266 2267File: gccint.info, Node: Passes, Next: Trees, Prev: Source Tree, Up: Top 2268 22697 Passes and Files of the Compiler 2270********************************** 2271 2272The overall control structure of the compiler is in `toplev.c'. This 2273file is responsible for initialization, decoding arguments, opening and 2274closing files, and sequencing the passes. Routines for emitting 2275diagnostic messages are defined in `diagnostic.c'. The files 2276`pretty-print.h' and `pretty-print.c' provide basic support for 2277language-independent pretty-printing. 2278 2279 The parsing pass is invoked only once, to parse the entire input. A 2280high level tree representation is then generated from the input, one 2281function at a time. This tree code is then transformed into RTL 2282intermediate code, and processed. The files involved in transforming 2283the trees into RTL are `expr.c', `expmed.c', and `stmt.c'. The order 2284of trees that are processed, is not necessarily the same order they are 2285generated from the input, due to deferred inlining, and other 2286considerations. 2287 2288 Each time the parsing pass reads a complete function definition or 2289top-level declaration, it calls either the function 2290`rest_of_compilation', or the function `rest_of_decl_compilation' in 2291`toplev.c', which are responsible for all further processing necessary, 2292ending with output of the assembler language. All other compiler 2293passes run, in sequence, within `rest_of_compilation'. When that 2294function returns from compiling a function definition, the storage used 2295for that function definition's compilation is entirely freed, unless it 2296is an inline function, or was deferred for some reason (this can occur 2297in templates, for example). (*note An Inline Function is As Fast As a 2298Macro: (gcc)Inline.). 2299 2300 Here is a list of all the passes of the compiler and their source 2301files. Also included is a description of where debugging dumps can be 2302requested with `-d' options. 2303 2304 * Parsing. This pass reads the entire text of a function definition, 2305 constructing a high level tree representation. (Because of the 2306 semantic analysis that takes place during this pass, it does more 2307 than is formally considered to be parsing.) 2308 2309 The tree representation does not entirely follow C syntax, because 2310 it is intended to support other languages as well. 2311 2312 Language-specific data type analysis is also done in this pass, 2313 and every tree node that represents an expression has a data type 2314 attached. Variables are represented as declaration nodes. 2315 2316 The language-independent source files for parsing are `tree.c', 2317 `fold-const.c', and `stor-layout.c'. There are also header files 2318 `tree.h' and `tree.def' which define the format of the tree 2319 representation. 2320 2321 C preprocessing, for language front ends, that want or require it, 2322 is performed by cpplib, which is covered in separate 2323 documentation. In particular, the internals are covered in *Note 2324 Cpplib internals: (cppinternals)Top. 2325 2326 The source files to parse C are found in the toplevel directory, 2327 and by convention are named `c-*'. Some of these are also used by 2328 the other C-like languages: `c-common.c', `c-common.def', 2329 `c-format.c', `c-opts.c', `c-pragma.c', `c-semantics.c', `c-lex.c', 2330 `c-incpath.c', `c-ppoutput.c', `c-cppbuiltin.c', `c-common.h', 2331 `c-dump.h', `c.opt', `c-incpath.h' and `c-pragma.h', 2332 2333 Files specific to each language are in subdirectories named after 2334 the language in question, like `ada', `objc', `cp' (for C++). 2335 2336 * Tree optimization. This is the optimization of the tree 2337 representation, before converting into RTL code. 2338 2339 Currently, the main optimization performed here is tree-based 2340 inlining. This is implemented in `tree-inline.c' and used by both 2341 C and C++. Note that tree based inlining turns off rtx based 2342 inlining (since it's more powerful, it would be a waste of time to 2343 do rtx based inlining in addition). 2344 2345 Constant folding and some arithmetic simplifications are also done 2346 during this pass, on the tree representation. The routines that 2347 perform these tasks are located in `fold-const.c'. 2348 2349 * RTL generation. This is the conversion of syntax tree into RTL 2350 code. 2351 2352 This is where the bulk of target-parameter-dependent code is found, 2353 since often it is necessary for strategies to apply only when 2354 certain standard kinds of instructions are available. The purpose 2355 of named instruction patterns is to provide this information to 2356 the RTL generation pass. 2357 2358 Optimization is done in this pass for `if'-conditions that are 2359 comparisons, boolean operations or conditional expressions. Tail 2360 recursion is detected at this time also. Decisions are made about 2361 how best to arrange loops and how to output `switch' statements. 2362 2363 The source files for RTL generation include `stmt.c', `calls.c', 2364 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and 2365 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the 2366 machine description by the program `genemit', is used in this 2367 pass. The header file `expr.h' is used for communication within 2368 this pass. 2369 2370 The header files `insn-flags.h' and `insn-codes.h', generated from 2371 the machine description by the programs `genflags' and `gencodes', 2372 tell this pass which standard names are available for use and 2373 which patterns correspond to them. 2374 2375 Aside from debugging information output, none of the following 2376 passes refers to the tree structure representation of the function 2377 (only part of which is saved). 2378 2379 The decision of whether the function can and should be expanded 2380 inline in its subsequent callers is made at the end of rtl 2381 generation. The function must meet certain criteria, currently 2382 related to the size of the function and the types and number of 2383 parameters it has. Note that this function may contain loops, 2384 recursive calls to itself (tail-recursive functions can be 2385 inlined!), gotos, in short, all constructs supported by GCC. The 2386 file `integrate.c' contains the code to save a function's rtl for 2387 later inlining and to inline that rtl when the function is called. 2388 The header file `integrate.h' is also used for this purpose. 2389 2390 The option `-dr' causes a debugging dump of the RTL code after 2391 this pass. This dump file's name is made by appending `.rtl' to 2392 the input file name. 2393 2394 * Sibling call optimization. This pass performs tail recursion 2395 elimination, and tail and sibling call optimizations. The purpose 2396 of these optimizations is to reduce the overhead of function calls, 2397 whenever possible. 2398 2399 The source file of this pass is `sibcall.c' 2400 2401 The option `-di' causes a debugging dump of the RTL code after 2402 this pass is run. This dump file's name is made by appending 2403 `.sibling' to the input file name. 2404 2405 * Jump optimization. This pass simplifies jumps to the following 2406 instruction, jumps across jumps, and jumps to jumps. It deletes 2407 unreferenced labels and unreachable code, except that unreachable 2408 code that contains a loop is not recognized as unreachable in this 2409 pass. (Such loops are deleted later in the basic block analysis.) 2410 It also converts some code originally written with jumps into 2411 sequences of instructions that directly set values from the 2412 results of comparisons, if the machine has such instructions. 2413 2414 Jump optimization is performed two or three times. The first time 2415 is immediately following RTL generation. The second time is after 2416 CSE, but only if CSE says repeated jump optimization is needed. 2417 The last time is right before the final pass. That time, 2418 cross-jumping and deletion of no-op move instructions are done 2419 together with the optimizations described above. 2420 2421 The source file of this pass is `jump.c'. 2422 2423 The option `-dj' causes a debugging dump of the RTL code after 2424 this pass is run for the first time. This dump file's name is 2425 made by appending `.jump' to the input file name. 2426 2427 * Register scan. This pass finds the first and last use of each 2428 register, as a guide for common subexpression elimination. Its 2429 source is in `regclass.c'. 2430 2431 * Jump threading. This pass detects a condition jump that branches 2432 to an identical or inverse test. Such jumps can be `threaded' 2433 through the second conditional test. The source code for this 2434 pass is in `jump.c'. This optimization is only performed if 2435 `-fthread-jumps' is enabled. 2436 2437 * Common subexpression elimination. This pass also does constant 2438 propagation. Its source files are `cse.c', and `cselib.c'. If 2439 constant propagation causes conditional jumps to become 2440 unconditional or to become no-ops, jump optimization is run again 2441 when CSE is finished. 2442 2443 The option `-ds' causes a debugging dump of the RTL code after 2444 this pass. This dump file's name is made by appending `.cse' to 2445 the input file name. 2446 2447 * Global common subexpression elimination. This pass performs two 2448 different types of GCSE depending on whether you are optimizing 2449 for size or not (LCM based GCSE tends to increase code size for a 2450 gain in speed, while Morel-Renvoise based GCSE does not). When 2451 optimizing for size, GCSE is done using Morel-Renvoise Partial 2452 Redundancy Elimination, with the exception that it does not try to 2453 move invariants out of loops--that is left to the loop 2454 optimization pass. If MR PRE GCSE is done, code hoisting (aka 2455 unification) is also done, as well as load motion. If you are 2456 optimizing for speed, LCM (lazy code motion) based GCSE is done. 2457 LCM is based on the work of Knoop, Ruthing, and Steffen. LCM 2458 based GCSE also does loop invariant code motion. We also perform 2459 load and store motion when optimizing for speed. Regardless of 2460 which type of GCSE is used, the GCSE pass also performs global 2461 constant and copy propagation. 2462 2463 The source file for this pass is `gcse.c', and the LCM routines 2464 are in `lcm.c'. 2465 2466 The option `-dG' causes a debugging dump of the RTL code after 2467 this pass. This dump file's name is made by appending `.gcse' to 2468 the input file name. 2469 2470 * Loop optimization. This pass moves constant expressions out of 2471 loops, and optionally does strength-reduction and loop unrolling 2472 as well. Its source files are `loop.c' and `unroll.c', plus the 2473 header `loop.h' used for communication between them. Loop 2474 unrolling uses some functions in `integrate.c' and the header 2475 `integrate.h'. Loop dependency analysis routines are contained in 2476 `dependence.c'. 2477 2478 Second loop optimization pass takes care of basic block level 2479 optimizations - unrolling, peeling and unswitching loops. The 2480 source files are `cfgloopanal.c' and `cfgloopmanip.c' containing 2481 generic loop analysis and manipulation code, `loop-init.c' with 2482 initialization and finalization code, `loop-unswitch.c' for loop 2483 unswitching and `loop-unroll.c' for loop unrolling and peeling. 2484 2485 The option `-dL' causes a debugging dump of the RTL code after 2486 these passes. The dump file names are made by appending `.loop' 2487 and `.loop2' to the input file name. 2488 2489 * Jump bypassing. This pass is an aggressive form of GCSE that 2490 transforms the control flow graph of a function by propagating 2491 constants into conditional branch instructions. 2492 2493 The source file for this pass is `gcse.c'. 2494 2495 The option `-dG' causes a debugging dump of the RTL code after 2496 this pass. This dump file's name is made by appending `.bypass' 2497 to the input file name. 2498 2499 * Simple optimization pass that splits independent uses of each 2500 pseudo increasing effect of other optimizations. This can improve 2501 effect of the other transformation, such as CSE or register 2502 allocation. Its source files are `web.c'. 2503 2504 The option `-dZ' causes a debugging dump of the RTL code after 2505 this pass. This dump file's name is made by appending `.web' to 2506 the input file name. 2507 2508 * If `-frerun-cse-after-loop' was enabled, a second common 2509 subexpression elimination pass is performed after the loop 2510 optimization pass. Jump threading is also done again at this time 2511 if it was specified. 2512 2513 The option `-dt' causes a debugging dump of the RTL code after 2514 this pass. This dump file's name is made by appending `.cse2' to 2515 the input file name. 2516 2517 * Data flow analysis (`flow.c'). This pass divides the program into 2518 basic blocks (and in the process deletes unreachable loops); then 2519 it computes which pseudo-registers are live at each point in the 2520 program, and makes the first instruction that uses a value point at 2521 the instruction that computed the value. 2522 2523 This pass also deletes computations whose results are never used, 2524 and combines memory references with add or subtract instructions 2525 to make autoincrement or autodecrement addressing. 2526 2527 The option `-df' causes a debugging dump of the RTL code after 2528 this pass. This dump file's name is made by appending `.flow' to 2529 the input file name. If stupid register allocation is in use, this 2530 dump file reflects the full results of such allocation. 2531 2532 * Instruction combination (`combine.c'). This pass attempts to 2533 combine groups of two or three instructions that are related by 2534 data flow into single instructions. It combines the RTL 2535 expressions for the instructions by substitution, simplifies the 2536 result using algebra, and then attempts to match the result 2537 against the machine description. 2538 2539 The option `-dc' causes a debugging dump of the RTL code after 2540 this pass. This dump file's name is made by appending `.combine' 2541 to the input file name. 2542 2543 * If-conversion is a transformation that transforms control 2544 dependencies into data dependencies (IE it transforms conditional 2545 code into a single control stream). It is implemented in the file 2546 `ifcvt.c'. 2547 2548 The option `-dE' causes a debugging dump of the RTL code after 2549 this pass. This dump file's name is made by appending `.ce' to 2550 the input file name. 2551 2552 * Register movement (`regmove.c'). This pass looks for cases where 2553 matching constraints would force an instruction to need a reload, 2554 and this reload would be a register-to-register move. It then 2555 attempts to change the registers used by the instruction to avoid 2556 the move instruction. 2557 2558 The option `-dN' causes a debugging dump of the RTL code after 2559 this pass. This dump file's name is made by appending `.regmove' 2560 to the input file name. 2561 2562 * Instruction scheduling (`sched.c'). This pass looks for 2563 instructions whose output will not be available by the time that 2564 it is used in subsequent instructions. (Memory loads and floating 2565 point instructions often have this behavior on RISC machines). It 2566 re-orders instructions within a basic block to try to separate the 2567 definition and use of items that otherwise would cause pipeline 2568 stalls. 2569 2570 Instruction scheduling is performed twice. The first time is 2571 immediately after instruction combination and the second is 2572 immediately after reload. 2573 2574 The option `-dS' causes a debugging dump of the RTL code after this 2575 pass is run for the first time. The dump file's name is made by 2576 appending `.sched' to the input file name. 2577 2578 * Register allocation. These passes make sure that all occurrences 2579 of pseudo registers are eliminated, either by allocating them to a 2580 hard register, replacing them by an equivalent expression (e.g. a 2581 constant) or by placing them on the stack. This is done in 2582 several subpasses: 2583 2584 * Register class preferencing. The RTL code is scanned to find 2585 out which register class is best for each pseudo register. 2586 The source file is `regclass.c'. 2587 2588 * Local register allocation (`local-alloc.c'). This pass 2589 allocates hard registers to pseudo registers that are used 2590 only within one basic block. Because the basic block is 2591 linear, it can use fast and powerful techniques to do a very 2592 good job. 2593 2594 The option `-dl' causes a debugging dump of the RTL code after 2595 this pass. This dump file's name is made by appending 2596 `.lreg' to the input file name. 2597 2598 * Global register allocation (`global.c'). This pass allocates 2599 hard registers for the remaining pseudo registers (those 2600 whose life spans are not contained in one basic block). 2601 2602 * Graph coloring register allocator. The files `ra.c', 2603 `ra-build.c', `ra-colorize.c', `ra-debug.c', `ra-rewrite.c' 2604 together with the header `ra.h' contain another register 2605 allocator, which is used when the option `-fnew-ra' is given. 2606 In that case it is run instead of the above mentioned local 2607 and global register allocation passes, and the option `-dl' 2608 causes a debugging dump of its work. 2609 2610 * Reloading. This pass renumbers pseudo registers with the 2611 hardware registers numbers they were allocated. Pseudo 2612 registers that did not get hard registers are replaced with 2613 stack slots. Then it finds instructions that are invalid 2614 because a value has failed to end up in a register, or has 2615 ended up in a register of the wrong kind. It fixes up these 2616 instructions by reloading the problematical values 2617 temporarily into registers. Additional instructions are 2618 generated to do the copying. 2619 2620 The reload pass also optionally eliminates the frame pointer 2621 and inserts instructions to save and restore call-clobbered 2622 registers around calls. 2623 2624 Source files are `reload.c' and `reload1.c', plus the header 2625 `reload.h' used for communication between them. 2626 2627 The option `-dg' causes a debugging dump of the RTL code after 2628 this pass. This dump file's name is made by appending 2629 `.greg' to the input file name. 2630 2631 * Instruction scheduling is repeated here to try to avoid pipeline 2632 stalls due to memory loads generated for spilled pseudo registers. 2633 2634 The option `-dR' causes a debugging dump of the RTL code after 2635 this pass. This dump file's name is made by appending `.sched2' 2636 to the input file name. 2637 2638 * Basic block reordering. This pass implements profile guided code 2639 positioning. If profile information is not available, various 2640 types of static analysis are performed to make the predictions 2641 normally coming from the profile feedback (IE execution frequency, 2642 branch probability, etc). It is implemented in the file 2643 `bb-reorder.c', and the various prediction routines are in 2644 `predict.c'. 2645 2646 The option `-dB' causes a debugging dump of the RTL code after 2647 this pass. This dump file's name is made by appending `.bbro' to 2648 the input file name. 2649 2650 * Delayed branch scheduling. This optional pass attempts to find 2651 instructions that can go into the delay slots of other 2652 instructions, usually jumps and calls. The source file name is 2653 `reorg.c'. 2654 2655 The option `-dd' causes a debugging dump of the RTL code after 2656 this pass. This dump file's name is made by appending `.dbr' to 2657 the input file name. 2658 2659 * Branch shortening. On many RISC machines, branch instructions 2660 have a limited range. Thus, longer sequences of instructions must 2661 be used for long branches. In this pass, the compiler figures out 2662 what how far each instruction will be from each other instruction, 2663 and therefore whether the usual instructions, or the longer 2664 sequences, must be used for each branch. 2665 2666 * Conversion from usage of some hard registers to usage of a register 2667 stack may be done at this point. Currently, this is supported only 2668 for the floating-point registers of the Intel 80387 coprocessor. 2669 The source file name is `reg-stack.c'. 2670 2671 The options `-dk' causes a debugging dump of the RTL code after 2672 this pass. This dump file's name is made by appending `.stack' to 2673 the input file name. 2674 2675 * Final. This pass outputs the assembler code for the function. It 2676 is also responsible for identifying spurious test and compare 2677 instructions. Machine-specific peephole optimizations are 2678 performed at the same time. The function entry and exit sequences 2679 are generated directly as assembler code in this pass; they never 2680 exist as RTL. 2681 2682 The source files are `final.c' plus `insn-output.c'; the latter is 2683 generated automatically from the machine description by the tool 2684 `genoutput'. The header file `conditions.h' is used for 2685 communication between these files. 2686 2687 * Debugging information output. This is run after final because it 2688 must output the stack slot offsets for pseudo registers that did 2689 not get hard registers. Source files are `dbxout.c' for DBX 2690 symbol table format, `sdbout.c' for SDB symbol table format, 2691 `dwarfout.c' for DWARF symbol table format, files `dwarf2out.c' and 2692 `dwarf2asm.c' for DWARF2 symbol table format, and `vmsdbgout.c' 2693 for VMS debug symbol table format. 2694 2695 Some additional files are used by all or many passes: 2696 2697 * Every pass uses `machmode.def' and `machmode.h' which define the 2698 machine modes. 2699 2700 * Several passes use `real.h', which defines the default 2701 representation of floating point constants and how to operate on 2702 them. 2703 2704 * All the passes that work with RTL use the header files `rtl.h' and 2705 `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also 2706 use these files to read and work with the machine description RTL. 2707 2708 * All the tools that read the machine description use support 2709 routines found in `gensupport.c', `errors.c', and `read-rtl.c'. 2710 2711 * Several passes refer to the header file `insn-config.h' which 2712 contains a few parameters (C macro definitions) generated 2713 automatically from the machine description RTL by the tool 2714 `genconfig'. 2715 2716 * Several passes use the instruction recognizer, which consists of 2717 `recog.c' and `recog.h', plus the files `insn-recog.c' and 2718 `insn-extract.c' that are generated automatically from the machine 2719 description by the tools `genrecog' and `genextract'. 2720 2721 * Several passes use the header files `regs.h' which defines the 2722 information recorded about pseudo register usage, and 2723 `basic-block.h' which defines the information recorded about basic 2724 blocks. 2725 2726 * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector 2727 with a bit for each hard register, and some macros to manipulate 2728 it. This type is just `int' if the machine has few enough hard 2729 registers; otherwise it is an array of `int' and some of the 2730 macros expand into loops. 2731 2732 * Several passes use instruction attributes. A definition of the 2733 attributes defined for a particular machine is in file 2734 `insn-attr.h', which is generated from the machine description by 2735 the program `genattr'. The file `insn-attrtab.c' contains 2736 subroutines to obtain the attribute values for insns and 2737 information about processor pipeline characteristics for the 2738 instruction scheduler. It is generated from the machine 2739 description by the program `genattrtab'. 2740 2741 2742File: gccint.info, Node: Trees, Next: RTL, Prev: Passes, Up: Top 2743 27448 Trees: The intermediate representation used by the C and C++ front ends 2745************************************************************************* 2746 2747This chapter documents the internal representation used by GCC to 2748represent C and C++ source programs. When presented with a C or C++ 2749source program, GCC parses the program, performs semantic analysis 2750(including the generation of error messages), and then produces the 2751internal representation described here. This representation contains a 2752complete representation for the entire translation unit provided as 2753input to the front end. This representation is then typically processed 2754by a code-generator in order to produce machine code, but could also be 2755used in the creation of source browsers, intelligent editors, automatic 2756documentation generators, interpreters, and any other programs needing 2757the ability to process C or C++ code. 2758 2759 This chapter explains the internal representation. In particular, it 2760documents the internal representation for C and C++ source constructs, 2761and the macros, functions, and variables that can be used to access 2762these constructs. The C++ representation is largely a superset of the 2763representation used in the C front end. There is only one construct 2764used in C that does not appear in the C++ front end and that is the GNU 2765"nested function" extension. Many of the macros documented here do not 2766apply in C because the corresponding language constructs do not appear 2767in C. 2768 2769 If you are developing a "back end", be it is a code-generator or some 2770other tool, that uses this representation, you may occasionally find 2771that you need to ask questions not easily answered by the functions and 2772macros available here. If that situation occurs, it is quite likely 2773that GCC already supports the functionality you desire, but that the 2774interface is simply not documented here. In that case, you should ask 2775the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 2776the functionality you require. Similarly, if you find yourself writing 2777functions that do not deal directly with your back end, but instead 2778might be useful to other people using the GCC front end, you should 2779submit your patches for inclusion in GCC. 2780 2781* Menu: 2782 2783* Deficiencies:: Topics net yet covered in this document. 2784* Tree overview:: All about `tree's. 2785* Types:: Fundamental and aggregate types. 2786* Scopes:: Namespaces and classes. 2787* Functions:: Overloading, function bodies, and linkage. 2788* Declarations:: Type declarations and variables. 2789* Attributes:: Declaration and type attributes. 2790* Expression trees:: From `typeid' to `throw'. 2791 2792 2793File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: Trees 2794 27958.1 Deficiencies 2796================ 2797 2798There are many places in which this document is incomplet and incorrekt. 2799It is, as of yet, only _preliminary_ documentation. 2800 2801 2802File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: Trees 2803 28048.2 Overview 2805============ 2806 2807The central data structure used by the internal representation is the 2808`tree'. These nodes, while all of the C type `tree', are of many 2809varieties. A `tree' is a pointer type, but the object to which it 2810points may be of a variety of types. From this point forward, we will 2811refer to trees in ordinary type, rather than in `this font', except 2812when talking about the actual C type `tree'. 2813 2814 You can tell what kind of node a particular tree is by using the 2815`TREE_CODE' macro. Many, many macros take trees as input and return 2816trees as output. However, most macros require a certain kind of tree 2817node as input. In other words, there is a type-system for trees, but 2818it is not reflected in the C type-system. 2819 2820 For safety, it is useful to configure GCC with `--enable-checking'. 2821Although this results in a significant performance penalty (since all 2822tree types are checked at run-time), and is therefore inappropriate in a 2823release version, it is extremely helpful during the development process. 2824 2825 Many macros behave as predicates. Many, although not all, of these 2826predicates end in `_P'. Do not rely on the result type of these macros 2827being of any particular type. You may, however, rely on the fact that 2828the type can be compared to `0', so that statements like 2829 if (TEST_P (t) && !TEST_P (y)) 2830 x = 1; 2831 and 2832 int i = (TEST_P (t) != 0); 2833 are legal. Macros that return `int' values now may be changed to 2834return `tree' values, or other pointers in the future. Even those that 2835continue to return `int' may return multiple nonzero codes where 2836previously they returned only zero and one. Therefore, you should not 2837write code like 2838 if (TEST_P (t) == 1) 2839 as this code is not guaranteed to work correctly in the future. 2840 2841 You should not take the address of values returned by the macros or 2842functions described here. In particular, no guarantee is given that the 2843values are lvalues. 2844 2845 In general, the names of macros are all in uppercase, while the 2846names of functions are entirely in lowercase. There are rare 2847exceptions to this rule. You should assume that any macro or function 2848whose name is made up entirely of uppercase letters may evaluate its 2849arguments more than once. You may assume that a macro or function 2850whose name is made up entirely of lowercase letters will evaluate its 2851arguments only once. 2852 2853 The `error_mark_node' is a special tree. Its tree code is 2854`ERROR_MARK', but since there is only ever one node with that code, the 2855usual practice is to compare the tree against `error_mark_node'. (This 2856test is just a test for pointer equality.) If an error has occurred 2857during front-end processing the flag `errorcount' will be set. If the 2858front end has encountered code it cannot handle, it will issue a 2859message to the user and set `sorrycount'. When these flags are set, 2860any macro or function which normally returns a tree of a particular 2861kind may instead return the `error_mark_node'. Thus, if you intend to 2862do any processing of erroneous code, you must be prepared to deal with 2863the `error_mark_node'. 2864 2865 Occasionally, a particular tree slot (like an operand to an 2866expression, or a particular field in a declaration) will be referred to 2867as "reserved for the back end." These slots are used to store RTL when 2868the tree is converted to RTL for use by the GCC back end. However, if 2869that process is not taking place (e.g., if the front end is being hooked 2870up to an intelligent editor), then those slots may be used by the back 2871end presently in use. 2872 2873 If you encounter situations that do not match this documentation, 2874such as tree nodes of types not mentioned here, or macros documented to 2875return entities of a particular kind that instead return entities of 2876some different kind, you have found a bug, either in the front end or in 2877the documentation. Please report these bugs as you would any other bug. 2878 2879* Menu: 2880 2881* Macros and Functions::Macros and functions that can be used with all trees. 2882* Identifiers:: The names of things. 2883* Containers:: Lists and vectors. 2884 2885 2886File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 2887 28888.2.1 Trees 2889----------- 2890 2891This section is not here yet. 2892 2893 2894File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 2895 28968.2.2 Identifiers 2897----------------- 2898 2899An `IDENTIFIER_NODE' represents a slightly more general concept that 2900the standard C or C++ concept of identifier. In particular, an 2901`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters. 2902 2903 There are never two distinct `IDENTIFIER_NODE's representing the 2904same identifier. Therefore, you may use pointer equality to compare 2905`IDENTIFIER_NODE's, rather than using a routine like `strcmp'. 2906 2907 You can use the following macros to access identifiers: 2908`IDENTIFIER_POINTER' 2909 The string represented by the identifier, represented as a 2910 `char*'. This string is always `NUL'-terminated, and contains no 2911 embedded `NUL' characters. 2912 2913`IDENTIFIER_LENGTH' 2914 The length of the string returned by `IDENTIFIER_POINTER', not 2915 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH 2916 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'. 2917 2918`IDENTIFIER_OPNAME_P' 2919 This predicate holds if the identifier represents the name of an 2920 overloaded operator. In this case, you should not depend on the 2921 contents of either the `IDENTIFIER_POINTER' or the 2922 `IDENTIFIER_LENGTH'. 2923 2924`IDENTIFIER_TYPENAME_P' 2925 This predicate holds if the identifier represents the name of a 2926 user-defined conversion operator. In this case, the `TREE_TYPE' of 2927 the `IDENTIFIER_NODE' holds the type to which the conversion 2928 operator converts. 2929 2930 2931 2932File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 2933 29348.2.3 Containers 2935---------------- 2936 2937Two common container data structures can be represented directly with 2938tree nodes. A `TREE_LIST' is a singly linked list containing two trees 2939per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node. 2940(Often, the `TREE_PURPOSE' contains some kind of tag, or additional 2941information, while the `TREE_VALUE' contains the majority of the 2942payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE', 2943while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of 2944equal stature.) Given one `TREE_LIST' node, the next node is found by 2945following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then 2946you have reached the end of the list. 2947 2948 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an 2949integer (not a tree) giving the number of nodes in the vector. The 2950nodes themselves are accessed using the `TREE_VEC_ELT' macro, which 2951takes two arguments. The first is the `TREE_VEC' in question; the 2952second is an integer indicating which element in the vector is desired. 2953The elements are indexed from zero. 2954 2955 2956File: gccint.info, Node: Types, Next: Scopes, Prev: Tree overview, Up: Trees 2957 29588.3 Types 2959========= 2960 2961All types have corresponding tree nodes. However, you should not assume 2962that there is exactly one tree node corresponding to each type. There 2963are often several nodes each of which correspond to the same type. 2964 2965 For the most part, different kinds of types have different tree 2966codes. (For example, pointer types use a `POINTER_TYPE' code while 2967arrays use an `ARRAY_TYPE' code.) However, pointers to member functions 2968use the `RECORD_TYPE' code. Therefore, when writing a `switch' 2969statement that depends on the code associated with a particular type, 2970you should take care to handle pointers to member functions under the 2971`RECORD_TYPE' case label. 2972 2973 In C++, an array type is not qualified; rather the type of the array 2974elements is qualified. This situation is reflected in the intermediate 2975representation. The macros described here will always examine the 2976qualification of the underlying element type when applied to an array 2977type. (If the element type is itself an array, then the recursion 2978continues until a non-array type is found, and the qualification of this 2979type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the 2980type `const int ()[7]', denoting an array of seven `int's. 2981 2982 The following functions and macros deal with cv-qualification of 2983types: 2984`CP_TYPE_QUALS' 2985 This macro returns the set of type qualifiers applied to this type. 2986 This value is `TYPE_UNQUALIFIED' if no qualifiers have been 2987 applied. The `TYPE_QUAL_CONST' bit is set if the type is 2988 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the 2989 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set 2990 if the type is `restrict'-qualified. 2991 2992`CP_TYPE_CONST_P' 2993 This macro holds if the type is `const'-qualified. 2994 2995`CP_TYPE_VOLATILE_P' 2996 This macro holds if the type is `volatile'-qualified. 2997 2998`CP_TYPE_RESTRICT_P' 2999 This macro holds if the type is `restrict'-qualified. 3000 3001`CP_TYPE_CONST_NON_VOLATILE_P' 3002 This predicate holds for a type that is `const'-qualified, but 3003 _not_ `volatile'-qualified; other cv-qualifiers are ignored as 3004 well: only the `const'-ness is tested. 3005 3006`TYPE_MAIN_VARIANT' 3007 This macro returns the unqualified version of a type. It may be 3008 applied to an unqualified type, but it is not always the identity 3009 function in that case. 3010 3011 A few other macros and functions are usable with all types: 3012`TYPE_SIZE' 3013 The number of bits required to represent the type, represented as 3014 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 3015 `NULL_TREE'. 3016 3017`TYPE_ALIGN' 3018 The alignment of the type, in bits, represented as an `int'. 3019 3020`TYPE_NAME' 3021 This macro returns a declaration (in the form of a `TYPE_DECL') for 3022 the type. (Note this macro does _not_ return a `IDENTIFIER_NODE', 3023 as you might expect, given its name!) You can look at the 3024 `DECL_NAME' of the `TYPE_DECL' to obtain the actual name of the 3025 type. The `TYPE_NAME' will be `NULL_TREE' for a type that is not 3026 a built-in type, the result of a typedef, or a named class type. 3027 3028`CP_INTEGRAL_TYPE' 3029 This predicate holds if the type is an integral type. Notice that 3030 in C++, enumerations are _not_ integral types. 3031 3032`ARITHMETIC_TYPE_P' 3033 This predicate holds if the type is an integral type (in the C++ 3034 sense) or a floating point type. 3035 3036`CLASS_TYPE_P' 3037 This predicate holds for a class-type. 3038 3039`TYPE_BUILT_IN' 3040 This predicate holds for a built-in type. 3041 3042`TYPE_PTRMEM_P' 3043 This predicate holds if the type is a pointer to data member. 3044 3045`TYPE_PTR_P' 3046 This predicate holds if the type is a pointer type, and the 3047 pointee is not a data member. 3048 3049`TYPE_PTRFN_P' 3050 This predicate holds for a pointer to function type. 3051 3052`TYPE_PTROB_P' 3053 This predicate holds for a pointer to object type. Note however 3054 that it does not hold for the generic pointer to object type `void 3055 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object 3056 type as well as `void *'. 3057 3058`same_type_p' 3059 This predicate takes two types as input, and holds if they are the 3060 same type. For example, if one type is a `typedef' for the other, 3061 or both are `typedef's for the same type. This predicate also 3062 holds if the two trees given as input are simply copies of one 3063 another; i.e., there is no difference between them at the source 3064 level, but, for whatever reason, a duplicate has been made in the 3065 representation. You should never use `==' (pointer equality) to 3066 compare types; always use `same_type_p' instead. 3067 3068 Detailed below are the various kinds of types, and the macros that 3069can be used to access them. Although other kinds of types are used 3070elsewhere in G++, the types described here are the only ones that you 3071will encounter while examining the intermediate representation. 3072 3073`VOID_TYPE' 3074 Used to represent the `void' type. 3075 3076`INTEGER_TYPE' 3077 Used to represent the various integral types, including `char', 3078 `short', `int', `long', and `long long'. This code is not used 3079 for enumeration types, nor for the `bool' type. Note that GCC's 3080 `CHAR_TYPE' node is _not_ used to represent `char'. The 3081 `TYPE_PRECISION' is the number of bits used in the representation, 3082 represented as an `unsigned int'. (Note that in the general case 3083 this is not the same value as `TYPE_SIZE'; suppose that there were 3084 a 24-bit integer type, but that alignment requirements for the ABI 3085 required 32-bit alignment. Then, `TYPE_SIZE' would be an 3086 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The 3087 integer type is unsigned if `TREE_UNSIGNED' holds; otherwise, it 3088 is signed. 3089 3090 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer 3091 that may be represented by this type. Similarly, the 3092 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that 3093 may be represented by this type. 3094 3095`REAL_TYPE' 3096 Used to represent the `float', `double', and `long double' types. 3097 The number of bits in the floating-point representation is given 3098 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case. 3099 3100`COMPLEX_TYPE' 3101 Used to represent GCC built-in `__complex__' data types. The 3102 `TREE_TYPE' is the type of the real and imaginary parts. 3103 3104`ENUMERAL_TYPE' 3105 Used to represent an enumeration type. The `TYPE_PRECISION' gives 3106 (as an `int'), the number of bits used to represent the type. If 3107 there are no negative enumeration constants, `TREE_UNSIGNED' will 3108 hold. The minimum and maximum enumeration constants may be 3109 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively; 3110 each of these macros returns an `INTEGER_CST'. 3111 3112 The actual enumeration constants themselves may be obtained by 3113 looking at the `TYPE_VALUES'. This macro will return a 3114 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each 3115 node will be an `IDENTIFIER_NODE' giving the name of the constant; 3116 the `TREE_VALUE' will be an `INTEGER_CST' giving the value 3117 assigned to that constant. These constants will appear in the 3118 order in which they were declared. The `TREE_TYPE' of each of 3119 these constants will be the type of enumeration type itself. 3120 3121`BOOLEAN_TYPE' 3122 Used to represent the `bool' type. 3123 3124`POINTER_TYPE' 3125 Used to represent pointer types, and pointer to data member types. 3126 The `TREE_TYPE' gives the type to which this type points. If the 3127 type is a pointer to data member type, then `TYPE_PTRMEM_P' will 3128 hold. For a pointer to data member type of the form `T X::*', 3129 `TYPE_PTRMEM_CLASS_TYPE' will be the type `X', while 3130 `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'. 3131 3132`REFERENCE_TYPE' 3133 Used to represent reference types. The `TREE_TYPE' gives the type 3134 to which this type refers. 3135 3136`FUNCTION_TYPE' 3137 Used to represent the type of non-member functions and of static 3138 member functions. The `TREE_TYPE' gives the return type of the 3139 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument 3140 types. The `TREE_VALUE' of each node in this list is the type of 3141 the corresponding argument; the `TREE_PURPOSE' is an expression 3142 for the default argument value, if any. If the last node in the 3143 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is 3144 the `void_type_node'), then functions of this type do not take 3145 variable arguments. Otherwise, they do take a variable number of 3146 arguments. 3147 3148 Note that in C (but not in C++) a function declared like `void f()' 3149 is an unprototyped function taking a variable number of arguments; 3150 the `TYPE_ARG_TYPES' of such a function will be `NULL'. 3151 3152`METHOD_TYPE' 3153 Used to represent the type of a non-static member function. Like a 3154 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The 3155 type of `*this', i.e., the class of which functions of this type 3156 are a member, is given by the `TYPE_METHOD_BASETYPE'. The 3157 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE', 3158 and includes the `this' argument. 3159 3160`ARRAY_TYPE' 3161 Used to represent array types. The `TREE_TYPE' gives the type of 3162 the elements in the array. If the array-bound is present in the 3163 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose 3164 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper 3165 bounds of the array, respectively. The `TYPE_MIN_VALUE' will 3166 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE' 3167 will be one less than the number of elements in the array, i.e., 3168 the highest value which may be used to index an element in the 3169 array. 3170 3171`RECORD_TYPE' 3172 Used to represent `struct' and `class' types, as well as pointers 3173 to member functions and similar constructs in other languages. 3174 `TYPE_FIELDS' contains the items contained in this type, each of 3175 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or 3176 `TYPE_DECL'. You may not make any assumptions about the ordering 3177 of the fields in the type or whether one or more of them overlap. 3178 If `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 3179 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a 3180 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is 3181 the type of a function pointed to by the pointer-to-member 3182 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a 3183 class type. For more information, see *note Classes::. 3184 3185`UNION_TYPE' 3186 Used to represent `union' types. Similar to `RECORD_TYPE' except 3187 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position 3188 zero. 3189 3190`QUAL_UNION_TYPE' 3191 Used to represent part of a variant record in Ada. Similar to 3192 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER' 3193 field, which contains a boolean expression that indicates whether 3194 the field is present in the object. The type will only have one 3195 field, so each field's `DECL_QUALIFIER' is only evaluated if none 3196 of the expressions in the previous fields in `TYPE_FIELDS' are 3197 nonzero. Normally these expressions will reference a field in the 3198 outer object using a `PLACEHOLDER_EXPR'. 3199 3200`UNKNOWN_TYPE' 3201 This node is used to represent a type the knowledge of which is 3202 insufficient for a sound processing. 3203 3204`OFFSET_TYPE' 3205 This node is used to represent a pointer-to-data member. For a 3206 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the 3207 `TREE_TYPE' is the type of `m'. 3208 3209`TYPENAME_TYPE' 3210 Used to represent a construct of the form `typename T::A'. The 3211 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for 3212 `A'. If the type is specified via a template-id, then 3213 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The 3214 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in 3215 support for the implicit typename extension; in which case the 3216 `TREE_TYPE' is a type node for the base-class. 3217 3218`TYPEOF_TYPE' 3219 Used to represent the `__typeof__' extension. The `TYPE_FIELDS' 3220 is the expression the type of which is being represented. 3221 3222 There are variables whose values represent some of the basic types. 3223These include: 3224`void_type_node' 3225 A node for `void'. 3226 3227`integer_type_node' 3228 A node for `int'. 3229 3230`unsigned_type_node.' 3231 A node for `unsigned int'. 3232 3233`char_type_node.' 3234 A node for `char'. 3235 It may sometimes be useful to compare one of these variables with a 3236type in hand, using `same_type_p'. 3237 3238 3239File: gccint.info, Node: Scopes, Next: Functions, Prev: Types, Up: Trees 3240 32418.4 Scopes 3242========== 3243 3244The root of the entire intermediate representation is the variable 3245`global_namespace'. This is the namespace specified with `::' in C++ 3246source code. All other namespaces, types, variables, functions, and so 3247forth can be found starting with this namespace. 3248 3249 Besides namespaces, the other high-level scoping construct in C++ is 3250the class. (Throughout this manual the term "class" is used to mean the 3251types referred to in the ANSI/ISO C++ Standard as classes; these include 3252types defined with the `class', `struct', and `union' keywords.) 3253 3254* Menu: 3255 3256* Namespaces:: Member functions, types, etc. 3257* Classes:: Members, bases, friends, etc. 3258 3259 3260File: gccint.info, Node: Namespaces, Next: Classes, Up: Scopes 3261 32628.4.1 Namespaces 3263---------------- 3264 3265A namespace is represented by a `NAMESPACE_DECL' node. 3266 3267 However, except for the fact that it is distinguished as the root of 3268the representation, the global namespace is no different from any other 3269namespace. Thus, in what follows, we describe namespaces generally, 3270rather than the global namespace in particular. 3271 3272 The following macros and functions can be used on a `NAMESPACE_DECL': 3273 3274`DECL_NAME' 3275 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to 3276 the unqualified name of the name of the namespace (*note 3277 Identifiers::). The name of the global namespace is `::', even 3278 though in C++ the global namespace is unnamed. However, you 3279 should use comparison with `global_namespace', rather than 3280 `DECL_NAME' to determine whether or not a namespace is the global 3281 one. An unnamed namespace will have a `DECL_NAME' equal to 3282 `anonymous_namespace_name'. Within a single translation unit, all 3283 unnamed namespaces will have the same name. 3284 3285`DECL_CONTEXT' 3286 This macro returns the enclosing namespace. The `DECL_CONTEXT' for 3287 the `global_namespace' is `NULL_TREE'. 3288 3289`DECL_NAMESPACE_ALIAS' 3290 If this declaration is for a namespace alias, then 3291 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 3292 alias. 3293 3294 Do not attempt to use `cp_namespace_decls' for a namespace which is 3295 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you 3296 reach an ordinary, non-alias, namespace, and call 3297 `cp_namespace_decls' there. 3298 3299`DECL_NAMESPACE_STD_P' 3300 This predicate holds if the namespace is the special `::std' 3301 namespace. 3302 3303`cp_namespace_decls' 3304 This function will return the declarations contained in the 3305 namespace, including types, overloaded functions, other 3306 namespaces, and so forth. If there are no declarations, this 3307 function will return `NULL_TREE'. The declarations are connected 3308 through their `TREE_CHAIN' fields. 3309 3310 Although most entries on this list will be declarations, 3311 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE' 3312 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is 3313 unspecified; back ends should ignore this value. As with the 3314 other kinds of declarations returned by `cp_namespace_decls', the 3315 `TREE_CHAIN' will point to the next declaration in this list. 3316 3317 For more information on the kinds of declarations that can occur 3318 on this list, *Note Declarations::. Some declarations will not 3319 appear on this list. In particular, no `FIELD_DECL', 3320 `LABEL_DECL', or `PARM_DECL' nodes will appear here. 3321 3322 This function cannot be used with namespaces that have 3323 `DECL_NAMESPACE_ALIAS' set. 3324 3325 3326 3327File: gccint.info, Node: Classes, Prev: Namespaces, Up: Scopes 3328 33298.4.2 Classes 3330------------- 3331 3332A class type is represented by either a `RECORD_TYPE' or a 3333`UNION_TYPE'. A class declared with the `union' tag is represented by 3334a `UNION_TYPE', while classes declared with either the `struct' or the 3335`class' tag are represented by `RECORD_TYPE's. You can use the 3336`CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 3337type is a `class' as opposed to a `struct'. This macro will be true 3338only for classes declared with the `class' tag. 3339 3340 Almost all non-function members are available on the `TYPE_FIELDS' 3341list. Given one member, the next can be found by following the 3342`TREE_CHAIN'. You should not depend in any way on the order in which 3343fields appear on this list. All nodes on this list will be `DECL' 3344nodes. A `FIELD_DECL' is used to represent a non-static data member, a 3345`VAR_DECL' is used to represent a static data member, and a `TYPE_DECL' 3346is used to represent a type. Note that the `CONST_DECL' for an 3347enumeration constant will appear on this list, if the enumeration type 3348was declared in the class. (Of course, the `TYPE_DECL' for the 3349enumeration type will appear here as well.) There are no entries for 3350base classes on this list. In particular, there is no `FIELD_DECL' for 3351the "base-class portion" of an object. 3352 3353 The `TYPE_VFIELD' is a compiler-generated field used to point to 3354virtual function tables. It may or may not appear on the `TYPE_FIELDS' 3355list. However, back ends should handle the `TYPE_VFIELD' just like all 3356the entries on the `TYPE_FIELDS' list. 3357 3358 The function members are available on the `TYPE_METHODS' list. 3359Again, subsequent members are found by following the `TREE_CHAIN' 3360field. If a function is overloaded, each of the overloaded functions 3361appears; no `OVERLOAD' nodes appear on the `TYPE_METHODS' list. 3362Implicitly declared functions (including default constructors, copy 3363constructors, assignment operators, and destructors) will appear on 3364this list as well. 3365 3366 Every class has an associated "binfo", which can be obtained with 3367`TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 3368given by `TYPE_BINFO' is the degenerate case, whereby every class is 3369considered to be its own base-class. The base classes for a particular 3370binfo can be obtained with `BINFO_BASETYPES'. These base-classes are 3371themselves binfos. The class type associated with a binfo is given by 3372`BINFO_TYPE'. It is always the case that `BINFO_TYPE (TYPE_BINFO (x))' 3373is the same type as `x', up to qualifiers. However, it is not always 3374the case that `TYPE_BINFO (BINFO_TYPE (y))' is always the same binfo as 3375`y'. The reason is that if `y' is a binfo representing a base-class 3376`B' of a derived class `D', then `BINFO_TYPE (y)' will be `B', and 3377`TYPE_BINFO (BINFO_TYPE (y))' will be `B' as its own base-class, rather 3378than as a base-class of `D'. 3379 3380 The `BINFO_BASETYPES' is a `TREE_VEC' (*note Containers::). Base 3381types appear in left-to-right order in this vector. You can tell 3382whether or `public', `protected', or `private' inheritance was used by 3383using the `TREE_VIA_PUBLIC', `TREE_VIA_PROTECTED', and 3384`TREE_VIA_PRIVATE' macros. Each of these macros takes a `BINFO' and is 3385true if and only if the indicated kind of inheritance was used. If 3386`TREE_VIA_VIRTUAL' holds of a binfo, then its `BINFO_TYPE' was 3387inherited from virtually. 3388 3389 The following macros can be used on a tree node representing a 3390class-type. 3391 3392`LOCAL_CLASS_P' 3393 This predicate holds if the class is local class _i.e._ declared 3394 inside a function body. 3395 3396`TYPE_POLYMORPHIC_P' 3397 This predicate holds if the class has at least one virtual function 3398 (declared or inherited). 3399 3400`TYPE_HAS_DEFAULT_CONSTRUCTOR' 3401 This predicate holds whenever its argument represents a class-type 3402 with default constructor. 3403 3404`CLASSTYPE_HAS_MUTABLE' 3405`TYPE_HAS_MUTABLE_P' 3406 These predicates hold for a class-type having a mutable data 3407 member. 3408 3409`CLASSTYPE_NON_POD_P' 3410 This predicate holds only for class-types that are not PODs. 3411 3412`TYPE_HAS_NEW_OPERATOR' 3413 This predicate holds for a class-type that defines `operator new'. 3414 3415`TYPE_HAS_ARRAY_NEW_OPERATOR' 3416 This predicate holds for a class-type for which `operator new[]' 3417 is defined. 3418 3419`TYPE_OVERLOADS_CALL_EXPR' 3420 This predicate holds for class-type for which the function call 3421 `operator()' is overloaded. 3422 3423`TYPE_OVERLOADS_ARRAY_REF' 3424 This predicate holds for a class-type that overloads `operator[]' 3425 3426`TYPE_OVERLOADS_ARROW' 3427 This predicate holds for a class-type for which `operator->' is 3428 overloaded. 3429 3430 3431 3432File: gccint.info, Node: Declarations, Next: Attributes, Prev: Functions, Up: Trees 3433 34348.5 Declarations 3435================ 3436 3437This section covers the various kinds of declarations that appear in the 3438internal representation, except for declarations of functions 3439(represented by `FUNCTION_DECL' nodes), which are described in *Note 3440Functions::. 3441 3442 Some macros can be used with any kind of declaration. These include: 3443`DECL_NAME' 3444 This macro returns an `IDENTIFIER_NODE' giving the name of the 3445 entity. 3446 3447`TREE_TYPE' 3448 This macro returns the type of the entity declared. 3449 3450`DECL_SOURCE_FILE' 3451 This macro returns the name of the file in which the entity was 3452 declared, as a `char*'. For an entity declared implicitly by the 3453 compiler (like `__builtin_memcpy'), this will be the string 3454 `"<internal>"'. 3455 3456`DECL_SOURCE_LINE' 3457 This macro returns the line number at which the entity was 3458 declared, as an `int'. 3459 3460`DECL_ARTIFICIAL' 3461 This predicate holds if the declaration was implicitly generated 3462 by the compiler. For example, this predicate will hold of an 3463 implicitly declared member function, or of the `TYPE_DECL' 3464 implicitly generated for a class type. Recall that in C++ code 3465 like: 3466 struct S {}; 3467 is roughly equivalent to C code like: 3468 struct S {}; 3469 typedef struct S S; 3470 The implicitly generated `typedef' declaration is represented by a 3471 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds. 3472 3473`DECL_NAMESPACE_SCOPE_P' 3474 This predicate holds if the entity was declared at a namespace 3475 scope. 3476 3477`DECL_CLASS_SCOPE_P' 3478 This predicate holds if the entity was declared at a class scope. 3479 3480`DECL_FUNCTION_SCOPE_P' 3481 This predicate holds if the entity was declared inside a function 3482 body. 3483 3484 3485 The various kinds of declarations include: 3486`LABEL_DECL' 3487 These nodes are used to represent labels in function bodies. For 3488 more information, see *Note Functions::. These nodes only appear 3489 in block scopes. 3490 3491`CONST_DECL' 3492 These nodes are used to represent enumeration constants. The 3493 value of the constant is given by `DECL_INITIAL' which will be an 3494 `INTEGER_CST' with the same type as the `TREE_TYPE' of the 3495 `CONST_DECL', i.e., an `ENUMERAL_TYPE'. 3496 3497`RESULT_DECL' 3498 These nodes represent the value returned by a function. When a 3499 value is assigned to a `RESULT_DECL', that indicates that the 3500 value should be returned, via bitwise copy, by the function. You 3501 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as 3502 with a `VAR_DECL'. 3503 3504`TYPE_DECL' 3505 These nodes represent `typedef' declarations. The `TREE_TYPE' is 3506 the type declared to have the name given by `DECL_NAME'. In some 3507 cases, there is no associated name. 3508 3509`VAR_DECL' 3510 These nodes represent variables with namespace or block scope, as 3511 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are 3512 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you 3513 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the 3514 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since 3515 special attributes may have been applied to the variable to give 3516 it a particular size and alignment. You may use the predicates 3517 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the 3518 storage class specifiers `static' or `extern' were used to declare 3519 a variable. 3520 3521 If this variable is initialized (but does not require a 3522 constructor), the `DECL_INITIAL' will be an expression for the 3523 initializer. The initializer should be evaluated, and a bitwise 3524 copy into the variable performed. If the `DECL_INITIAL' is the 3525 `error_mark_node', there is an initializer, but it is given by an 3526 explicit statement later in the code; no bitwise copy is required. 3527 3528 GCC provides an extension that allows either automatic variables, 3529 or global variables, to be placed in particular registers. This 3530 extension is being used for a particular `VAR_DECL' if 3531 `DECL_REGISTER' holds for the `VAR_DECL', and if 3532 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case, 3533 `DECL_ASSEMBLER_NAME' is the name of the register into which the 3534 variable will be placed. 3535 3536`PARM_DECL' 3537 Used to represent a parameter to a function. Treat these nodes 3538 similarly to `VAR_DECL' nodes. These nodes only appear in the 3539 `DECL_ARGUMENTS' for a `FUNCTION_DECL'. 3540 3541 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will 3542 actually be used when a value is passed to this function. It may 3543 be a wider type than the `TREE_TYPE' of the parameter; for 3544 example, the ordinary type might be `short' while the 3545 `DECL_ARG_TYPE' is `int'. 3546 3547`FIELD_DECL' 3548 These nodes represent non-static data members. The `DECL_SIZE' and 3549 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The 3550 `DECL_FIELD_BITPOS' gives the first bit used for this field, as an 3551 `INTEGER_CST'. These values are indexed from zero, where zero 3552 indicates the first bit in the object. 3553 3554 If `DECL_C_BIT_FIELD' holds, this field is a bit-field. 3555 3556`NAMESPACE_DECL' 3557 *Note Namespaces::. 3558 3559`TEMPLATE_DECL' 3560 These nodes are used to represent class, function, and variable 3561 (static data member) templates. The 3562 `DECL_TEMPLATE_SPECIALIZATIONS' are a `TREE_LIST'. The 3563 `TREE_VALUE' of each node in the list is a `TEMPLATE_DECL's or 3564 `FUNCTION_DECL's representing specializations (including 3565 instantiations) of this template. Back ends can safely ignore 3566 `TEMPLATE_DECL's, but should examine `FUNCTION_DECL' nodes on the 3567 specializations list just as they would ordinary `FUNCTION_DECL' 3568 nodes. 3569 3570 For a class template, the `DECL_TEMPLATE_INSTANTIATIONS' list 3571 contains the instantiations. The `TREE_VALUE' of each node is an 3572 instantiation of the class. The `DECL_TEMPLATE_SPECIALIZATIONS' 3573 contains partial specializations of the class. 3574 3575`USING_DECL' 3576 Back ends can safely ignore these nodes. 3577 3578 3579 3580File: gccint.info, Node: Functions, Next: Declarations, Prev: Scopes, Up: Trees 3581 35828.6 Functions 3583============= 3584 3585A function is represented by a `FUNCTION_DECL' node. A set of 3586overloaded functions is sometimes represented by a `OVERLOAD' node. 3587 3588 An `OVERLOAD' node is not a declaration, so none of the `DECL_' 3589macros should be used on an `OVERLOAD'. An `OVERLOAD' node is similar 3590to a `TREE_LIST'. Use `OVL_CURRENT' to get the function associated 3591with an `OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node 3592in the list of overloaded functions. The macros `OVL_CURRENT' and 3593`OVL_NEXT' are actually polymorphic; you can use them to work with 3594`FUNCTION_DECL' nodes as well as with overloads. In the case of a 3595`FUNCTION_DECL', `OVL_CURRENT' will always return the function itself, 3596and `OVL_NEXT' will always be `NULL_TREE'. 3597 3598 To determine the scope of a function, you can use the `DECL_CONTEXT' 3599macro. This macro will return the class (either a `RECORD_TYPE' or a 3600`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 3601is a member. For a virtual function, this macro returns the class in 3602which the function was actually defined, not the base class in which 3603the virtual declaration occurred. 3604 3605 If a friend function is defined in a class scope, the 3606`DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 3607it was defined. For example, in 3608 class C { friend void f() {} }; 3609 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the 3610`DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'. 3611 3612 In C, the `DECL_CONTEXT' for a function maybe another function. 3613This representation indicates that the GNU nested function extension is 3614in use. For details on the semantics of nested functions, see the GCC 3615Manual. The nested function can refer to local variables in its 3616containing function. Such references are not explicitly marked in the 3617tree structure; back ends must look at the `DECL_CONTEXT' for the 3618referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced 3619`VAR_DECL' is not the same as the function currently being processed, 3620and neither `DECL_EXTERNAL' nor `DECL_STATIC' hold, then the reference 3621is to a local variable in a containing function, and the back end must 3622take appropriate action. 3623 3624* Menu: 3625 3626* Function Basics:: Function names, linkage, and so forth. 3627* Function Bodies:: The statements that make up a function body. 3628 3629 3630File: gccint.info, Node: Function Basics, Next: Function Bodies, Up: Functions 3631 36328.6.1 Function Basics 3633--------------------- 3634 3635The following macros and functions can be used on a `FUNCTION_DECL': 3636`DECL_MAIN_P' 3637 This predicate holds for a function that is the program entry point 3638 `::code'. 3639 3640`DECL_NAME' 3641 This macro returns the unqualified name of the function, as an 3642 `IDENTIFIER_NODE'. For an instantiation of a function template, 3643 the `DECL_NAME' is the unqualified name of the template, not 3644 something like `f<int>'. The value of `DECL_NAME' is undefined 3645 when used on a constructor, destructor, overloaded operator, or 3646 type-conversion operator, or any function that is implicitly 3647 generated by the compiler. See below for macros that can be used 3648 to distinguish these cases. 3649 3650`DECL_ASSEMBLER_NAME' 3651 This macro returns the mangled name of the function, also an 3652 `IDENTIFIER_NODE'. This name does not contain leading underscores 3653 on systems that prefix all identifiers with underscores. The 3654 mangled name is computed in the same way on all platforms; if 3655 special processing is required to deal with the object file format 3656 used on a particular platform, it is the responsibility of the 3657 back end to perform those modifications. (Of course, the back end 3658 should not modify `DECL_ASSEMBLER_NAME' itself.) 3659 3660`DECL_EXTERNAL' 3661 This predicate holds if the function is undefined. 3662 3663`TREE_PUBLIC' 3664 This predicate holds if the function has external linkage. 3665 3666`DECL_LOCAL_FUNCTION_P' 3667 This predicate holds if the function was declared at block scope, 3668 even though it has a global scope. 3669 3670`DECL_ANTICIPATED' 3671 This predicate holds if the function is a built-in function but its 3672 prototype is not yet explicitly declared. 3673 3674`DECL_EXTERN_C_FUNCTION_P' 3675 This predicate holds if the function is declared as an ``extern 3676 "C"'' function. 3677 3678`DECL_LINKONCE_P' 3679 This macro holds if multiple copies of this function may be 3680 emitted in various translation units. It is the responsibility of 3681 the linker to merge the various copies. Template instantiations 3682 are the most common example of functions for which 3683 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all 3684 translation units which require them, and then relies on the 3685 linker to remove duplicate instantiations. 3686 3687 FIXME: This macro is not yet implemented. 3688 3689`DECL_FUNCTION_MEMBER_P' 3690 This macro holds if the function is a member of a class, rather 3691 than a member of a namespace. 3692 3693`DECL_STATIC_FUNCTION_P' 3694 This predicate holds if the function a static member function. 3695 3696`DECL_NONSTATIC_MEMBER_FUNCTION_P' 3697 This macro holds for a non-static member function. 3698 3699`DECL_CONST_MEMFUNC_P' 3700 This predicate holds for a `const'-member function. 3701 3702`DECL_VOLATILE_MEMFUNC_P' 3703 This predicate holds for a `volatile'-member function. 3704 3705`DECL_CONSTRUCTOR_P' 3706 This macro holds if the function is a constructor. 3707 3708`DECL_NONCONVERTING_P' 3709 This predicate holds if the constructor is a non-converting 3710 constructor. 3711 3712`DECL_COMPLETE_CONSTRUCTOR_P' 3713 This predicate holds for a function which is a constructor for an 3714 object of a complete type. 3715 3716`DECL_BASE_CONSTRUCTOR_P' 3717 This predicate holds for a function which is a constructor for a 3718 base class sub-object. 3719 3720`DECL_COPY_CONSTRUCTOR_P' 3721 This predicate holds for a function which is a copy-constructor. 3722 3723`DECL_DESTRUCTOR_P' 3724 This macro holds if the function is a destructor. 3725 3726`DECL_COMPLETE_DESTRUCTOR_P' 3727 This predicate holds if the function is the destructor for an 3728 object a complete type. 3729 3730`DECL_OVERLOADED_OPERATOR_P' 3731 This macro holds if the function is an overloaded operator. 3732 3733`DECL_CONV_FN_P' 3734 This macro holds if the function is a type-conversion operator. 3735 3736`DECL_GLOBAL_CTOR_P' 3737 This predicate holds if the function is a file-scope initialization 3738 function. 3739 3740`DECL_GLOBAL_DTOR_P' 3741 This predicate holds if the function is a file-scope finalization 3742 function. 3743 3744`DECL_THUNK_P' 3745 This predicate holds if the function is a thunk. 3746 3747 These functions represent stub code that adjusts the `this' pointer 3748 and then jumps to another function. When the jumped-to function 3749 returns, control is transferred directly to the caller, without 3750 returning to the thunk. The first parameter to the thunk is 3751 always the `this' pointer; the thunk should add `THUNK_DELTA' to 3752 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) 3753 3754 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the 3755 adjusted `this' pointer must be adjusted again. The complete 3756 calculation is given by the following pseudo-code: 3757 3758 this += THUNK_DELTA 3759 if (THUNK_VCALL_OFFSET) 3760 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 3761 3762 Finally, the thunk should jump to the location given by 3763 `DECL_INITIAL'; this will always be an expression for the address 3764 of a function. 3765 3766`DECL_NON_THUNK_FUNCTION_P' 3767 This predicate holds if the function is _not_ a thunk function. 3768 3769`GLOBAL_INIT_PRIORITY' 3770 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then 3771 this gives the initialization priority for the function. The 3772 linker will arrange that all functions for which 3773 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 3774 before `main' is called. When the program exits, all functions for 3775 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 3776 3777`DECL_ARTIFICIAL' 3778 This macro holds if the function was implicitly generated by the 3779 compiler, rather than explicitly declared. In addition to 3780 implicitly generated class member functions, this macro holds for 3781 the special functions created to implement static initialization 3782 and destruction, to compute run-time type information, and so 3783 forth. 3784 3785`DECL_ARGUMENTS' 3786 This macro returns the `PARM_DECL' for the first argument to the 3787 function. Subsequent `PARM_DECL' nodes can be obtained by 3788 following the `TREE_CHAIN' links. 3789 3790`DECL_RESULT' 3791 This macro returns the `RESULT_DECL' for the function. 3792 3793`TREE_TYPE' 3794 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the 3795 function. 3796 3797`TYPE_RAISES_EXCEPTIONS' 3798 This macro returns the list of exceptions that a (member-)function 3799 can raise. The returned list, if non `NULL', is comprised of nodes 3800 whose `TREE_VALUE' represents a type. 3801 3802`TYPE_NOTHROW_P' 3803 This predicate holds when the exception-specification of its 3804 arguments if of the form ``()''. 3805 3806`DECL_ARRAY_DELETE_OPERATOR_P' 3807 This predicate holds if the function an overloaded `operator 3808 delete[]'. 3809 3810 3811 3812File: gccint.info, Node: Function Bodies, Prev: Function Basics, Up: Functions 3813 38148.6.2 Function Bodies 3815--------------------- 3816 3817A function that has a definition in the current translation unit will 3818have a non-`NULL' `DECL_INITIAL'. However, back ends should not make 3819use of the particular value given by `DECL_INITIAL'. 3820 3821 The `DECL_SAVED_TREE' macro will give the complete body of the 3822function. This node will usually be a `COMPOUND_STMT' representing the 3823outermost block of the function, but it may also be a `TRY_BLOCK', a 3824`RETURN_INIT', or any other valid statement. 3825 38268.6.2.1 Statements 3827.................. 3828 3829There are tree nodes corresponding to all of the source-level statement 3830constructs. These are enumerated here, together with a list of the 3831various macros that can be used to obtain information about them. There 3832are a few macros that can be used with all statements: 3833 3834`STMT_LINENO' 3835 This macro returns the line number for the statement. If the 3836 statement spans multiple lines, this value will be the number of 3837 the first line on which the statement occurs. Although we mention 3838 `CASE_LABEL' below as if it were a statement, they do not allow 3839 the use of `STMT_LINENO'. There is no way to obtain the line 3840 number for a `CASE_LABEL'. 3841 3842 Statements do not contain information about the file from which 3843 they came; that information is implicit in the `FUNCTION_DECL' 3844 from which the statements originate. 3845 3846`STMT_IS_FULL_EXPR_P' 3847 In C++, statements normally constitute "full expressions"; 3848 temporaries created during a statement are destroyed when the 3849 statement is complete. However, G++ sometimes represents 3850 expressions by statements; these statements will not have 3851 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such 3852 statements should be destroyed when the innermost enclosing 3853 statement with `STMT_IS_FULL_EXPR_P' set is exited. 3854 3855 3856 Here is the list of the various statement nodes, and the macros used 3857to access them. This documentation describes the use of these nodes in 3858non-template functions (including instantiations of template functions). 3859In template functions, the same nodes are used, but sometimes in 3860slightly different ways. 3861 3862 Many of the statements have substatements. For example, a `while' 3863loop will have a body, which is itself a statement. If the substatement 3864is `NULL_TREE', it is considered equivalent to a statement consisting 3865of a single `;', i.e., an expression statement in which the expression 3866has been omitted. A substatement may in fact be a list of statements, 3867connected via their `TREE_CHAIN's. So, you should always process the 3868statement tree by looping over substatements, like this: 3869 void process_stmt (stmt) 3870 tree stmt; 3871 { 3872 while (stmt) 3873 { 3874 switch (TREE_CODE (stmt)) 3875 { 3876 case IF_STMT: 3877 process_stmt (THEN_CLAUSE (stmt)); 3878 /* More processing here. */ 3879 break; 3880 3881 ... 3882 } 3883 3884 stmt = TREE_CHAIN (stmt); 3885 } 3886 } 3887 In other words, while the `then' clause of an `if' statement in C++ 3888can be only one statement (although that one statement may be a 3889compound statement), the intermediate representation will sometimes use 3890several statements chained together. 3891 3892`ASM_STMT' 3893 Used to represent an inline assembly statement. For an inline 3894 assembly statement like: 3895 asm ("mov x, y"); 3896 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov 3897 x, y"'. If the original statement made use of the 3898 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and 3899 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the 3900 statement, represented as `STRING_CST' nodes. The 3901 extended-assembly syntax looks like: 3902 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 3903 The first string is the `ASM_STRING', containing the instruction 3904 template. The next two strings are the output and inputs, 3905 respectively; this statement has no clobbers. As this example 3906 indicates, "plain" assembly statements are merely a special case 3907 of extended assembly statements; they have no cv-qualifiers, 3908 outputs, inputs, or clobbers. All of the strings will be 3909 `NUL'-terminated, and will contain no embedded `NUL'-characters. 3910 3911 If the assembly statement is declared `volatile', or if the 3912 statement was not an extended assembly statement, and is therefore 3913 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold 3914 of the `ASM_STMT'. 3915 3916`BREAK_STMT' 3917 Used to represent a `break' statement. There are no additional 3918 fields. 3919 3920`CASE_LABEL' 3921 Use to represent a `case' label, range of `case' labels, or a 3922 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a 3923 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then 3924 this is an ordinary `case' label. In this case, `CASE_LOW' is an 3925 expression giving the value of the label. Both `CASE_LOW' and 3926 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the 3927 same type as the condition expression in the switch statement. 3928 3929 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the 3930 statement is a range of case labels. Such statements originate 3931 with the extension that allows users to write things of the form: 3932 case 2 ... 5: 3933 The first value will be `CASE_LOW', while the second will be 3934 `CASE_HIGH'. 3935 3936`CLEANUP_STMT' 3937 Used to represent an action that should take place upon exit from 3938 the enclosing scope. Typically, these actions are calls to 3939 destructors for local objects, but back ends cannot rely on this 3940 fact. If these nodes are in fact representing such destructors, 3941 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, 3942 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the 3943 `CLEANUP_EXPR' is the expression to execute. The cleanups 3944 executed on exit from a scope should be run in the reverse order 3945 of the order in which the associated `CLEANUP_STMT's were 3946 encountered. 3947 3948`COMPOUND_STMT' 3949 Used to represent a brace-enclosed block. The first substatement 3950 is given by `COMPOUND_BODY'. Subsequent substatements are found by 3951 following the `TREE_CHAIN' link from one substatement to the next. 3952 The `COMPOUND_BODY' will be `NULL_TREE' if there are no 3953 substatements. 3954 3955`CONTINUE_STMT' 3956 Used to represent a `continue' statement. There are no additional 3957 fields. 3958 3959`CTOR_STMT' 3960 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if 3961 `CTOR_END_P' holds of the main body of a constructor. See also 3962 `SUBOBJECT' for more information on how to use these nodes. 3963 3964`DECL_STMT' 3965 Used to represent a local declaration. The `DECL_STMT_DECL' macro 3966 can be used to obtain the entity declared. This declaration may 3967 be a `LABEL_DECL', indicating that the label declared is a local 3968 label. (As an extension, GCC allows the declaration of labels 3969 with scope.) In C, this declaration may be a `FUNCTION_DECL', 3970 indicating the use of the GCC nested function extension. For more 3971 information, *note Functions::. 3972 3973`DO_STMT' 3974 Used to represent a `do' loop. The body of the loop is given by 3975 `DO_BODY' while the termination condition for the loop is given by 3976 `DO_COND'. The condition for a `do'-statement is always an 3977 expression. 3978 3979`EMPTY_CLASS_EXPR' 3980 Used to represent a temporary object of a class with no data whose 3981 address is never taken. (All such objects are interchangeable.) 3982 The `TREE_TYPE' represents the type of the object. 3983 3984`EXPR_STMT' 3985 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to 3986 obtain the expression. 3987 3988`FILE_STMT' 3989 Used to record a change in filename within the body of a function. 3990 Use `FILE_STMT_FILENAME' to obtain the new filename. 3991 3992`FOR_STMT' 3993 Used to represent a `for' statement. The `FOR_INIT_STMT' is the 3994 initialization statement for the loop. The `FOR_COND' is the 3995 termination condition. The `FOR_EXPR' is the expression executed 3996 right before the `FOR_COND' on each loop iteration; often, this 3997 expression increments a counter. The body of the loop is given by 3998 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return 3999 statements, while `FOR_COND' and `FOR_EXPR' return expressions. 4000 4001`GOTO_STMT' 4002 Used to represent a `goto' statement. The `GOTO_DESTINATION' will 4003 usually be a `LABEL_DECL'. However, if the "computed goto" 4004 extension has been used, the `GOTO_DESTINATION' will be an 4005 arbitrary expression indicating the destination. This expression 4006 will always have pointer type. Additionally the `GOTO_FAKE_P' 4007 flag is set whenever the goto statement does not come from source 4008 code, but it is generated implicitly by the compiler. This is 4009 used for branch prediction. 4010 4011`HANDLER' 4012 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the 4013 type of exception that will be caught by this handler; it is equal 4014 (by pointer equality) to `NULL' if this handler is for all types. 4015 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and 4016 `HANDLER_BODY' is the `COMPOUND_STMT' for the block itself. 4017 4018`IF_STMT' 4019 Used to represent an `if' statement. The `IF_COND' is the 4020 expression. 4021 4022 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a 4023 statement (usually a `DECL_STMT'). Each time the condition is 4024 evaluated, the statement should be executed. Then, the 4025 `TREE_VALUE' should be used as the conditional expression itself. 4026 This representation is used to handle C++ code like this: 4027 4028 if (int i = 7) ... 4029 4030 where there is a new local variable (or variables) declared within 4031 the condition. 4032 4033 The `THEN_CLAUSE' represents the statement given by the `then' 4034 condition, while the `ELSE_CLAUSE' represents the statement given 4035 by the `else' condition. 4036 4037`LABEL_STMT' 4038 Used to represent a label. The `LABEL_DECL' declared by this 4039 statement can be obtained with the `LABEL_STMT_LABEL' macro. The 4040 `IDENTIFIER_NODE' giving the name of the label can be obtained from 4041 the `LABEL_DECL' with `DECL_NAME'. 4042 4043`RETURN_INIT' 4044 If the function uses the G++ "named return value" extension, 4045 meaning that the function has been defined like: 4046 S f(int) return s {...} 4047 then there will be a `RETURN_INIT'. There is never a named 4048 returned value for a constructor. The first argument to the 4049 `RETURN_INIT' is the name of the object returned; the second 4050 argument is the initializer for the object. The object is 4051 initialized when the `RETURN_INIT' is encountered. The object 4052 referred to is the actual object returned; this extension is a 4053 manual way of doing the "return-value optimization." Therefore, 4054 the object must actually be constructed in the place where the 4055 object will be returned. 4056 4057`RETURN_STMT' 4058 Used to represent a `return' statement. The `RETURN_EXPR' is the 4059 expression returned; it will be `NULL_TREE' if the statement was 4060 just 4061 return; 4062 4063`SCOPE_STMT' 4064 A scope-statement represents the beginning or end of a scope. If 4065 `SCOPE_BEGIN_P' holds, this statement represents the beginning of a 4066 scope; if `SCOPE_END_P' holds this statement represents the end of 4067 a scope. On exit from a scope, all cleanups from `CLEANUP_STMT's 4068 occurring in the scope must be run, in reverse order to the order 4069 in which they were encountered. If `SCOPE_NULLIFIED_P' or 4070 `SCOPE_NO_CLEANUPS_P' holds of the scope, back ends should behave 4071 as if the `SCOPE_STMT' were not present at all. 4072 4073`SUBOBJECT' 4074 In a constructor, these nodes are used to mark the point at which a 4075 subobject of `this' is fully constructed. If, after this point, an 4076 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is 4077 encountered, the `SUBOBJECT_CLEANUP' must be executed. The 4078 cleanups must be executed in the reverse order in which they 4079 appear. 4080 4081`SWITCH_STMT' 4082 Used to represent a `switch' statement. The `SWITCH_COND' is the 4083 expression on which the switch is occurring. See the documentation 4084 for an `IF_STMT' for more information on the representation used 4085 for the condition. The `SWITCH_BODY' is the body of the switch 4086 statement. The `SWITCH_TYPE' is the original type of switch 4087 expression as given in the source, before any compiler conversions. 4088 4089`TRY_BLOCK' 4090 Used to represent a `try' block. The body of the try block is 4091 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' 4092 node. The first handler is given by `TRY_HANDLERS'. Subsequent 4093 handlers are obtained by following the `TREE_CHAIN' link from one 4094 handler to the next. The body of the handler is given by 4095 `HANDLER_BODY'. 4096 4097 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' 4098 will not be a `HANDLER' node. Instead, it will be an expression 4099 that should be executed if an exception is thrown in the try 4100 block. It must rethrow the exception after executing that code. 4101 And, if an exception is thrown while the expression is executing, 4102 `terminate' must be called. 4103 4104`USING_STMT' 4105 Used to represent a `using' directive. The namespace is given by 4106 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 4107 is needed inside template functions, to implement using directives 4108 during instantiation. 4109 4110`WHILE_STMT' 4111 Used to represent a `while' loop. The `WHILE_COND' is the 4112 termination condition for the loop. See the documentation for an 4113 `IF_STMT' for more information on the representation used for the 4114 condition. 4115 4116 The `WHILE_BODY' is the body of the loop. 4117 4118 4119 4120File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: Trees 4121 41228.7 Attributes in trees 4123======================= 4124 4125Attributes, as specified using the `__attribute__' keyword, are 4126represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the 4127name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a 4128`TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' 4129if there are no arguments; the arguments are stored as the `TREE_VALUE' 4130of successive entries in the list, and may be identifiers or 4131expressions. The `TREE_CHAIN' of the attribute is the next attribute 4132in a list of attributes applying to the same declaration or type, or 4133`NULL_TREE' if there are no further attributes in the list. 4134 4135 Attributes may be attached to declarations and to types; these 4136attributes may be accessed with the following macros. All attributes 4137are stored in this way, and many also cause other changes to the 4138declaration or type or to other internal compiler data structures. 4139 4140 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 4141 This macro returns the attributes on the declaration DECL. 4142 4143 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 4144 This macro returns the attributes on the type TYPE. 4145 4146 4147File: gccint.info, Node: Expression trees, Prev: Attributes, Up: Trees 4148 41498.8 Expressions 4150=============== 4151 4152The internal representation for expressions is for the most part quite 4153straightforward. However, there are a few facts that one must bear in 4154mind. In particular, the expression "tree" is actually a directed 4155acyclic graph. (For example there may be many references to the integer 4156constant zero throughout the source program; many of these will be 4157represented by the same expression node.) You should not rely on 4158certain kinds of node being shared, nor should rely on certain kinds of 4159nodes being unshared. 4160 4161 The following macros can be used with all expression nodes: 4162 4163`TREE_TYPE' 4164 Returns the type of the expression. This value may not be 4165 precisely the same type that would be given the expression in the 4166 original program. 4167 4168 In what follows, some nodes that one might expect to always have type 4169`bool' are documented to have either integral or boolean type. At some 4170point in the future, the C front end may also make use of this same 4171intermediate representation, and at this point these nodes will 4172certainly have integral type. The previous sentence is not meant to 4173imply that the C++ front end does not or will not give these nodes 4174integral type. 4175 4176 Below, we list the various kinds of expression nodes. Except where 4177noted otherwise, the operands to an expression are accessed using the 4178`TREE_OPERAND' macro. For example, to access the first operand to a 4179binary plus expression `expr', use: 4180 4181 TREE_OPERAND (expr, 0) 4182 As this example indicates, the operands are zero-indexed. 4183 4184 The table below begins with constants, moves on to unary expressions, 4185then proceeds to binary expressions, and concludes with various other 4186kinds of expressions: 4187 4188`INTEGER_CST' 4189 These nodes represent integer constants. Note that the type of 4190 these constants is obtained with `TREE_TYPE'; they are not always 4191 of type `int'. In particular, `char' constants are represented 4192 with `INTEGER_CST' nodes. The value of the integer constant `e' is 4193 given by 4194 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT) 4195 + TREE_INST_CST_LOW (e)) 4196 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. 4197 Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a 4198 `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as 4199 a signed or unsigned quantity depending on the type of the 4200 constant. In general, the expression given above will overflow, 4201 so it should not be used to calculate the value of the constant. 4202 4203 The variable `integer_zero_node' is an integer constant with value 4204 zero. Similarly, `integer_one_node' is an integer constant with 4205 value one. The `size_zero_node' and `size_one_node' variables are 4206 analogous, but have type `size_t' rather than `int'. 4207 4208 The function `tree_int_cst_lt' is a predicate which holds if its 4209 first argument is less than its second. Both constants are 4210 assumed to have the same signedness (i.e., either both should be 4211 signed or both should be unsigned.) The full width of the 4212 constant is used when doing the comparison; the usual rules about 4213 promotions and conversions are ignored. Similarly, 4214 `tree_int_cst_equal' holds if the two constants are equal. The 4215 `tree_int_cst_sgn' function returns the sign of a constant. The 4216 value is `1', `0', or `-1' according on whether the constant is 4217 greater than, equal to, or less than zero. Again, the signedness 4218 of the constant's type is taken into account; an unsigned constant 4219 is never less than zero, no matter what its bit-pattern. 4220 4221`REAL_CST' 4222 FIXME: Talk about how to obtain representations of this constant, 4223 do comparisons, and so forth. 4224 4225`COMPLEX_CST' 4226 These nodes are used to represent complex number constants, that 4227 is a `__complex__' whose parts are constant nodes. The 4228 `TREE_REALPART' and `TREE_IMAGPART' return the real and the 4229 imaginary parts respectively. 4230 4231`VECTOR_CST' 4232 These nodes are used to represent vector constants, whose parts are 4233 constant nodes. Each individual constant node is either an 4234 integer or a double constant node. The first operand is a 4235 `TREE_LIST' of the constant nodes and is accessed through 4236 `TREE_VECTOR_CST_ELTS'. 4237 4238`STRING_CST' 4239 These nodes represent string-constants. The `TREE_STRING_LENGTH' 4240 returns the length of the string, as an `int'. The 4241 `TREE_STRING_POINTER' is a `char*' containing the string itself. 4242 The string may not be `NUL'-terminated, and it may contain 4243 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' 4244 includes the trailing `NUL' if it is present. 4245 4246 For wide string constants, the `TREE_STRING_LENGTH' is the number 4247 of bytes in the string, and the `TREE_STRING_POINTER' points to an 4248 array of the bytes of the string, as represented on the target 4249 system (that is, as integers in the target endianness). Wide and 4250 non-wide string constants are distinguished only by the `TREE_TYPE' 4251 of the `STRING_CST'. 4252 4253 FIXME: The formats of string constants are not well-defined when 4254 the target system bytes are not the same width as host system 4255 bytes. 4256 4257`PTRMEM_CST' 4258 These nodes are used to represent pointer-to-member constants. The 4259 `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or 4260 `UNION_TYPE' within which the pointer points), and the 4261 `PTRMEM_CST_MEMBER' is the declaration for the pointed to object. 4262 Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in 4263 general different from the `PTRMEM_CST_CLASS'. For example, given: 4264 struct B { int i; }; 4265 struct D : public B {}; 4266 int D::*dp = &D::i; 4267 The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the 4268 `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is 4269 a member of `B', not `D'. 4270 4271`VAR_DECL' 4272 These nodes represent variables, including static data members. 4273 For more information, *note Declarations::. 4274 4275`NEGATE_EXPR' 4276 These nodes represent unary negation of the single operand, for 4277 both integer and floating-point types. The type of negation can be 4278 determined by looking at the type of the expression. 4279 4280 The behavior of this operation on signed arithmetic overflow is 4281 controlled by the `flag_wrapv' and `flag_trapv' variables. 4282 4283`ABS_EXPR' 4284 These nodes represent the absolute value of the single operand, for 4285 both integer and floating-point types. This is typically used to 4286 implement the `abs', `labs' and `llabs' builtins for integer 4287 types, and the `fabs', `fabsf' and `fabsl' builtins for floating 4288 point types. The type of abs operation can be determined by 4289 looking at the type of the expression. 4290 4291 This node is not used for complex types. To represent the modulus 4292 or complex abs of a complex value, use the `BUILT_IN_CABS', 4293 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to 4294 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions. 4295 4296`BIT_NOT_EXPR' 4297 These nodes represent bitwise complement, and will always have 4298 integral type. The only operand is the value to be complemented. 4299 4300`TRUTH_NOT_EXPR' 4301 These nodes represent logical negation, and will always have 4302 integral (or boolean) type. The operand is the value being 4303 negated. 4304 4305`PREDECREMENT_EXPR' 4306`PREINCREMENT_EXPR' 4307`POSTDECREMENT_EXPR' 4308`POSTINCREMENT_EXPR' 4309 These nodes represent increment and decrement expressions. The 4310 value of the single operand is computed, and the operand 4311 incremented or decremented. In the case of `PREDECREMENT_EXPR' and 4312 `PREINCREMENT_EXPR', the value of the expression is the value 4313 resulting after the increment or decrement; in the case of 4314 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before 4315 the increment or decrement occurs. The type of the operand, like 4316 that of the result, will be either integral, boolean, or 4317 floating-point. 4318 4319`ADDR_EXPR' 4320 These nodes are used to represent the address of an object. (These 4321 expressions will always have pointer or reference type.) The 4322 operand may be another expression, or it may be a declaration. 4323 4324 As an extension, GCC allows users to take the address of a label. 4325 In this case, the operand of the `ADDR_EXPR' will be a 4326 `LABEL_DECL'. The type of such an expression is `void*'. 4327 4328 If the object addressed is not an lvalue, a temporary is created, 4329 and the address of the temporary is used. 4330 4331`INDIRECT_REF' 4332 These nodes are used to represent the object pointed to by a 4333 pointer. The operand is the pointer being dereferenced; it will 4334 always have pointer or reference type. 4335 4336`FIX_TRUNC_EXPR' 4337 These nodes represent conversion of a floating-point value to an 4338 integer. The single operand will have a floating-point type, 4339 while the the complete expression will have an integral (or 4340 boolean) type. The operand is rounded towards zero. 4341 4342`FLOAT_EXPR' 4343 These nodes represent conversion of an integral (or boolean) value 4344 to a floating-point value. The single operand will have integral 4345 type, while the complete expression will have a floating-point 4346 type. 4347 4348 FIXME: How is the operand supposed to be rounded? Is this 4349 dependent on `-mieee'? 4350 4351`COMPLEX_EXPR' 4352 These nodes are used to represent complex numbers constructed from 4353 two expressions of the same (integer or real) type. The first 4354 operand is the real part and the second operand is the imaginary 4355 part. 4356 4357`CONJ_EXPR' 4358 These nodes represent the conjugate of their operand. 4359 4360`REALPART_EXPR' 4361`IMAGPART_EXPR' 4362 These nodes represent respectively the real and the imaginary parts 4363 of complex numbers (their sole argument). 4364 4365`NON_LVALUE_EXPR' 4366 These nodes indicate that their one and only operand is not an 4367 lvalue. A back end can treat these identically to the single 4368 operand. 4369 4370`NOP_EXPR' 4371 These nodes are used to represent conversions that do not require 4372 any code-generation. For example, conversion of a `char*' to an 4373 `int*' does not require any code be generated; such a conversion is 4374 represented by a `NOP_EXPR'. The single operand is the expression 4375 to be converted. The conversion from a pointer to a reference is 4376 also represented with a `NOP_EXPR'. 4377 4378`CONVERT_EXPR' 4379 These nodes are similar to `NOP_EXPR's, but are used in those 4380 situations where code may need to be generated. For example, if an 4381 `int*' is converted to an `int' code may need to be generated on 4382 some platforms. These nodes are never used for C++-specific 4383 conversions, like conversions between pointers to different 4384 classes in an inheritance hierarchy. Any adjustments that need to 4385 be made in such cases are always indicated explicitly. Similarly, 4386 a user-defined conversion is never represented by a 4387 `CONVERT_EXPR'; instead, the function calls are made explicit. 4388 4389`THROW_EXPR' 4390 These nodes represent `throw' expressions. The single operand is 4391 an expression for the code that should be executed to throw the 4392 exception. However, there is one implicit action not represented 4393 in that expression; namely the call to `__throw'. This function 4394 takes no arguments. If `setjmp'/`longjmp' exceptions are used, the 4395 function `__sjthrow' is called instead. The normal GCC back end 4396 uses the function `emit_throw' to generate this code; you can 4397 examine this function to see what needs to be done. 4398 4399`LSHIFT_EXPR' 4400`RSHIFT_EXPR' 4401 These nodes represent left and right shifts, respectively. The 4402 first operand is the value to shift; it will always be of integral 4403 type. The second operand is an expression for the number of bits 4404 by which to shift. Right shift should be treated as arithmetic, 4405 i.e., the high-order bits should be zero-filled when the 4406 expression has unsigned type and filled with the sign bit when the 4407 expression has signed type. Note that the result is undefined if 4408 the second operand is larger than the first operand's type size. 4409 4410`BIT_IOR_EXPR' 4411`BIT_XOR_EXPR' 4412`BIT_AND_EXPR' 4413 These nodes represent bitwise inclusive or, bitwise exclusive or, 4414 and bitwise and, respectively. Both operands will always have 4415 integral type. 4416 4417`TRUTH_ANDIF_EXPR' 4418`TRUTH_ORIF_EXPR' 4419 These nodes represent logical and and logical or, respectively. 4420 These operators are not strict; i.e., the second operand is 4421 evaluated only if the value of the expression is not determined by 4422 evaluation of the first operand. The type of the operands, and 4423 the result type, is always of boolean or integral type. 4424 4425`TRUTH_AND_EXPR' 4426`TRUTH_OR_EXPR' 4427`TRUTH_XOR_EXPR' 4428 These nodes represent logical and, logical or, and logical 4429 exclusive or. They are strict; both arguments are always 4430 evaluated. There are no corresponding operators in C or C++, but 4431 the front end will sometimes generate these expressions anyhow, if 4432 it can tell that strictness does not matter. 4433 4434`PLUS_EXPR' 4435`MINUS_EXPR' 4436`MULT_EXPR' 4437`TRUNC_DIV_EXPR' 4438`TRUNC_MOD_EXPR' 4439`RDIV_EXPR' 4440 These nodes represent various binary arithmetic operations. 4441 Respectively, these operations are addition, subtraction (of the 4442 second operand from the first), multiplication, integer division, 4443 integer remainder, and floating-point division. The operands to 4444 the first three of these may have either integral or floating 4445 type, but there will never be case in which one operand is of 4446 floating type and the other is of integral type. 4447 4448 The result of a `TRUNC_DIV_EXPR' is always rounded towards zero. 4449 The `TRUNC_MOD_EXPR' of two operands `a' and `b' is always `a - 4450 (a/b)*b' where the division is as if computed by a 4451 `TRUNC_DIV_EXPR'. 4452 4453 The behavior of these operations on signed arithmetic overflow is 4454 controlled by the `flag_wrapv' and `flag_trapv' variables. 4455 4456`ARRAY_REF' 4457 These nodes represent array accesses. The first operand is the 4458 array; the second is the index. To calculate the address of the 4459 memory accessed, you must scale the index by the size of the type 4460 of the array elements. The type of these expressions must be the 4461 type of a component of the array. 4462 4463`ARRAY_RANGE_REF' 4464 These nodes represent access to a range (or "slice") of an array. 4465 The operands are the same as that for `ARRAY_REF' and have the same 4466 meanings. The type of these expressions must be an array whose 4467 component type is the same as that of the first operand. The 4468 range of that array type determines the amount of data these 4469 expressions access. 4470 4471`EXACT_DIV_EXPR' 4472 Document. 4473 4474`LT_EXPR' 4475`LE_EXPR' 4476`GT_EXPR' 4477`GE_EXPR' 4478`EQ_EXPR' 4479`NE_EXPR' 4480 These nodes represent the less than, less than or equal to, greater 4481 than, greater than or equal to, equal, and not equal comparison 4482 operators. The first and second operand with either be both of 4483 integral type or both of floating type. The result type of these 4484 expressions will always be of integral or boolean type. 4485 4486`MODIFY_EXPR' 4487 These nodes represent assignment. The left-hand side is the first 4488 operand; the right-hand side is the second operand. The left-hand 4489 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or 4490 other lvalue. 4491 4492 These nodes are used to represent not only assignment with `=' but 4493 also compound assignments (like `+='), by reduction to `=' 4494 assignment. In other words, the representation for `i += 3' looks 4495 just like that for `i = i + 3'. 4496 4497`INIT_EXPR' 4498 These nodes are just like `MODIFY_EXPR', but are used only when a 4499 variable is initialized, rather than assigned to subsequently. 4500 4501`COMPONENT_REF' 4502 These nodes represent non-static data member accesses. The first 4503 operand is the object (rather than a pointer to it); the second 4504 operand is the `FIELD_DECL' for the data member. 4505 4506`COMPOUND_EXPR' 4507 These nodes represent comma-expressions. The first operand is an 4508 expression whose value is computed and thrown away prior to the 4509 evaluation of the second operand. The value of the entire 4510 expression is the value of the second operand. 4511 4512`COND_EXPR' 4513 These nodes represent `?:' expressions. The first operand is of 4514 boolean or integral type. If it evaluates to a nonzero value, the 4515 second operand should be evaluated, and returned as the value of 4516 the expression. Otherwise, the third operand is evaluated, and 4517 returned as the value of the expression. 4518 4519 The second operand must have the same type as the entire 4520 expression, unless it unconditionally throws an exception or calls 4521 a noreturn function, in which case it should have void type. The 4522 same constraints apply to the third operand. This allows array 4523 bounds checks to be represented conveniently as `(i >= 0 && i < 4524 10) ? i : abort()'. 4525 4526 As a GNU extension, the C language front-ends allow the second 4527 operand of the `?:' operator may be omitted in the source. For 4528 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x' 4529 is an expression without side-effects. In the tree 4530 representation, however, the second operand is always present, 4531 possibly protected by `SAVE_EXPR' if the first argument does cause 4532 side-effects. 4533 4534`CALL_EXPR' 4535 These nodes are used to represent calls to functions, including 4536 non-static member functions. The first operand is a pointer to the 4537 function to call; it is always an expression whose type is a 4538 `POINTER_TYPE'. The second argument is a `TREE_LIST'. The 4539 arguments to the call appear left-to-right in the list. The 4540 `TREE_VALUE' of each list node contains the expression 4541 corresponding to that argument. (The value of `TREE_PURPOSE' for 4542 these nodes is unspecified, and should be ignored.) For non-static 4543 member functions, there will be an operand corresponding to the 4544 `this' pointer. There will always be expressions corresponding to 4545 all of the arguments, even if the function is declared with default 4546 arguments and some arguments are not explicitly provided at the 4547 call sites. 4548 4549`STMT_EXPR' 4550 These nodes are used to represent GCC's statement-expression 4551 extension. The statement-expression extension allows code like 4552 this: 4553 int f() { return ({ int j; j = 3; j + 7; }); } 4554 In other words, an sequence of statements may occur where a single 4555 expression would normally appear. The `STMT_EXPR' node represents 4556 such an expression. The `STMT_EXPR_STMT' gives the statement 4557 contained in the expression; this is always a `COMPOUND_STMT'. The 4558 value of the expression is the value of the last sub-statement in 4559 the `COMPOUND_STMT'. More precisely, the value is the value 4560 computed by the last `EXPR_STMT' in the outermost scope of the 4561 `COMPOUND_STMT'. For example, in: 4562 ({ 3; }) 4563 the value is `3' while in: 4564 ({ if (x) { 3; } }) 4565 (represented by a nested `COMPOUND_STMT'), there is no value. If 4566 the `STMT_EXPR' does not yield a value, it's type will be `void'. 4567 4568`BIND_EXPR' 4569 These nodes represent local blocks. The first operand is a list of 4570 temporary variables, connected via their `TREE_CHAIN' field. These 4571 will never require cleanups. The scope of these variables is just 4572 the body of the `BIND_EXPR'. The body of the `BIND_EXPR' is the 4573 second operand. 4574 4575`LOOP_EXPR' 4576 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' 4577 represents the body of the loop. It should be executed forever, 4578 unless an `EXIT_EXPR' is encountered. 4579 4580`EXIT_EXPR' 4581 These nodes represent conditional exits from the nearest enclosing 4582 `LOOP_EXPR'. The single operand is the condition; if it is 4583 nonzero, then the loop should be exited. An `EXIT_EXPR' will only 4584 appear within a `LOOP_EXPR'. 4585 4586`CLEANUP_POINT_EXPR' 4587 These nodes represent full-expressions. The single operand is an 4588 expression to evaluate. Any destructor calls engendered by the 4589 creation of temporaries during the evaluation of that expression 4590 should be performed immediately after the expression is evaluated. 4591 4592`CONSTRUCTOR' 4593 These nodes represent the brace-enclosed initializers for a 4594 structure or array. The first operand is reserved for use by the 4595 back end. The second operand is a `TREE_LIST'. If the 4596 `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or 4597 `UNION_TYPE', then the `TREE_PURPOSE' of each node in the 4598 `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each 4599 node will be the expression used to initialize that field. 4600 4601 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then 4602 the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an 4603 `INTEGER_CST'. This constant indicates which element of the array 4604 (indexed from zero) is being assigned to; again, the `TREE_VALUE' 4605 is the corresponding initializer. If the `TREE_PURPOSE' is 4606 `NULL_TREE', then the initializer is for the next available array 4607 element. 4608 4609 In the front end, you should not depend on the fields appearing in 4610 any particular order. However, in the middle end, fields must 4611 appear in declaration order. You should not assume that all 4612 fields will be represented. Unrepresented fields will be set to 4613 zero. 4614 4615`COMPOUND_LITERAL_EXPR' 4616 These nodes represent ISO C99 compound literals. The 4617 `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' containing an 4618 anonymous `VAR_DECL' for the unnamed object represented by the 4619 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a 4620 `CONSTRUCTOR' representing the brace-enclosed list of initializers 4621 in the compound literal. That anonymous `VAR_DECL' can also be 4622 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. 4623 4624`SAVE_EXPR' 4625 A `SAVE_EXPR' represents an expression (possibly involving 4626 side-effects) that is used more than once. The side-effects should 4627 occur only the first time the expression is evaluated. Subsequent 4628 uses should just reuse the computed value. The first operand to 4629 the `SAVE_EXPR' is the expression to evaluate. The side-effects 4630 should be executed where the `SAVE_EXPR' is first encountered in a 4631 depth-first preorder traversal of the expression tree. 4632 4633`TARGET_EXPR' 4634 A `TARGET_EXPR' represents a temporary object. The first operand 4635 is a `VAR_DECL' for the temporary variable. The second operand is 4636 the initializer for the temporary. The initializer is evaluated, 4637 and copied (bitwise) into the temporary. 4638 4639 Often, a `TARGET_EXPR' occurs on the right-hand side of an 4640 assignment, or as the second operand to a comma-expression which is 4641 itself the right-hand side of an assignment, etc. In this case, 4642 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is 4643 "orphaned". For a normal `TARGET_EXPR' the temporary variable 4644 should be treated as an alias for the left-hand side of the 4645 assignment, rather than as a new temporary variable. 4646 4647 The third operand to the `TARGET_EXPR', if present, is a 4648 cleanup-expression (i.e., destructor call) for the temporary. If 4649 this expression is orphaned, then this expression must be executed 4650 when the statement containing this expression is complete. These 4651 cleanups must always be executed in the order opposite to that in 4652 which they were encountered. Note that if a temporary is created 4653 on one branch of a conditional operator (i.e., in the second or 4654 third operand to a `COND_EXPR'), the cleanup must be run only if 4655 that branch is actually executed. 4656 4657 See `STMT_IS_FULL_EXPR_P' for more information about running these 4658 cleanups. 4659 4660`AGGR_INIT_EXPR' 4661 An `AGGR_INIT_EXPR' represents the initialization as the return 4662 value of a function call, or as the result of a constructor. An 4663 `AGGR_INIT_EXPR' will only appear as the second operand of a 4664 `TARGET_EXPR'. The first operand to the `AGGR_INIT_EXPR' is the 4665 address of a function to call, just as in a `CALL_EXPR'. The 4666 second operand are the arguments to pass that function, as a 4667 `TREE_LIST', again in a manner similar to that of a `CALL_EXPR'. 4668 The value of the expression is that returned by the function. 4669 4670 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the 4671 initialization is via a constructor call. The address of the third 4672 operand of the `AGGR_INIT_EXPR', which is always a `VAR_DECL', is 4673 taken, and this value replaces the first argument in the argument 4674 list. In this case, the value of the expression is the `VAR_DECL' 4675 given by the third operand to the `AGGR_INIT_EXPR'; constructors do 4676 not return a value. 4677 4678`VTABLE_REF' 4679 A `VTABLE_REF' indicates that the interior expression computes a 4680 value that is a vtable entry. It is used with `-fvtable-gc' to 4681 track the reference through to front end to the middle end, at 4682 which point we transform this to a `REG_VTABLE_REF' note, which 4683 survives the balance of code generation. 4684 4685 The first operand is the expression that computes the vtable 4686 reference. The second operand is the `VAR_DECL' of the vtable. 4687 The third operand is an `INTEGER_CST' of the byte offset into the 4688 vtable. 4689 4690`VA_ARG_EXPR' 4691 This node is used to implement support for the C/C++ variable 4692 argument-list mechanism. It represents expressions like `va_arg 4693 (ap, type)'. Its `TREE_TYPE' yields the tree representation for 4694 `type' and its sole argument yields the representation for `ap'. 4695 4696 4697 4698File: gccint.info, Node: RTL, Next: Machine Desc, Prev: Trees, Up: Top 4699 47009 RTL Representation 4701******************** 4702 4703Most of the work of the compiler is done on an intermediate 4704representation called register transfer language. In this language, 4705the instructions to be output are described, pretty much one by one, in 4706an algebraic form that describes what the instruction does. 4707 4708 RTL is inspired by Lisp lists. It has both an internal form, made 4709up of structures that point at other structures, and a textual form 4710that is used in the machine description and in printed debugging dumps. 4711The textual form uses nested parentheses to indicate the pointers in 4712the internal form. 4713 4714* Menu: 4715 4716* RTL Objects:: Expressions vs vectors vs strings vs integers. 4717* RTL Classes:: Categories of RTL expression objects, and their structure. 4718* Accessors:: Macros to access expression operands or vector elts. 4719* Special Accessors:: Macros to access specific annotations on RTL. 4720* Flags:: Other flags in an RTL expression. 4721* Machine Modes:: Describing the size and format of a datum. 4722* Constants:: Expressions with constant values. 4723* Regs and Memory:: Expressions representing register contents or memory. 4724* Arithmetic:: Expressions representing arithmetic on other expressions. 4725* Comparisons:: Expressions representing comparison of expressions. 4726* Bit-Fields:: Expressions representing bit-fields in memory or reg. 4727* Vector Operations:: Expressions involving vector datatypes. 4728* Conversions:: Extending, truncating, floating or fixing. 4729* RTL Declarations:: Declaring volatility, constancy, etc. 4730* Side Effects:: Expressions for storing in registers, etc. 4731* Incdec:: Embedded side-effects for autoincrement addressing. 4732* Assembler:: Representing `asm' with operands. 4733* Insns:: Expression types for entire insns. 4734* Calls:: RTL representation of function call insns. 4735* Sharing:: Some expressions are unique; others *must* be copied. 4736* Reading RTL:: Reading textual RTL from a file. 4737 4738 4739File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 4740 47419.1 RTL Object Types 4742==================== 4743 4744RTL uses five kinds of objects: expressions, integers, wide integers, 4745strings and vectors. Expressions are the most important ones. An RTL 4746expression ("RTX", for short) is a C structure, but it is usually 4747referred to with a pointer; a type that is given the typedef name `rtx'. 4748 4749 An integer is simply an `int'; their written form uses decimal 4750digits. A wide integer is an integral object whose type is 4751`HOST_WIDE_INT'; their written form uses decimal digits. 4752 4753 A string is a sequence of characters. In core it is represented as a 4754`char *' in usual C fashion, and it is written in C syntax as well. 4755However, strings in RTL may never be null. If you write an empty 4756string in a machine description, it is represented in core as a null 4757pointer rather than as a pointer to a null character. In certain 4758contexts, these null pointers instead of strings are valid. Within RTL 4759code, strings are most commonly found inside `symbol_ref' expressions, 4760but they appear in other contexts in the RTL expressions that make up 4761machine descriptions. 4762 4763 In a machine description, strings are normally written with double 4764quotes, as you would in C. However, strings in machine descriptions may 4765extend over many lines, which is invalid C, and adjacent string 4766constants are not concatenated as they are in C. Any string constant 4767may be surrounded with a single set of parentheses. Sometimes this 4768makes the machine description easier to read. 4769 4770 There is also a special syntax for strings, which can be useful when 4771C code is embedded in a machine description. Wherever a string can 4772appear, it is also valid to write a C-style brace block. The entire 4773brace block, including the outermost pair of braces, is considered to be 4774the string constant. Double quote characters inside the braces are not 4775special. Therefore, if you write string constants in the C code, you 4776need not escape each quote character with a backslash. 4777 4778 A vector contains an arbitrary number of pointers to expressions. 4779The number of elements in the vector is explicitly present in the 4780vector. The written form of a vector consists of square brackets 4781(`[...]') surrounding the elements, in sequence and with whitespace 4782separating them. Vectors of length zero are not created; null pointers 4783are used instead. 4784 4785 Expressions are classified by "expression codes" (also called RTX 4786codes). The expression code is a name defined in `rtl.def', which is 4787also (in uppercase) a C enumeration constant. The possible expression 4788codes and their meanings are machine-independent. The code of an RTX 4789can be extracted with the macro `GET_CODE (X)' and altered with 4790`PUT_CODE (X, NEWCODE)'. 4791 4792 The expression code determines how many operands the expression 4793contains, and what kinds of objects they are. In RTL, unlike Lisp, you 4794cannot tell by looking at an operand what kind of object it is. 4795Instead, you must know from its context--from the expression code of 4796the containing expression. For example, in an expression of code 4797`subreg', the first operand is to be regarded as an expression and the 4798second operand as an integer. In an expression of code `plus', there 4799are two operands, both of which are to be regarded as expressions. In 4800a `symbol_ref' expression, there is one operand, which is to be 4801regarded as a string. 4802 4803 Expressions are written as parentheses containing the name of the 4804expression type, its flags and machine mode if any, and then the 4805operands of the expression (separated by spaces). 4806 4807 Expression code names in the `md' file are written in lowercase, but 4808when they appear in C code they are written in uppercase. In this 4809manual, they are shown as follows: `const_int'. 4810 4811 In a few contexts a null pointer is valid where an expression is 4812normally wanted. The written form of this is `(nil)'. 4813 4814 4815File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 4816 48179.2 RTL Classes and Formats 4818=========================== 4819 4820The various expression codes are divided into several "classes", which 4821are represented by single characters. You can determine the class of 4822an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently, 4823`rtx.def' defines these classes: 4824 4825`o' 4826 An RTX code that represents an actual object, such as a register 4827 (`REG') or a memory location (`MEM', `SYMBOL_REF'). Constants and 4828 basic transforms on objects (`ADDRESSOF', `HIGH', `LO_SUM') are 4829 also included. Note that `SUBREG' and `STRICT_LOW_PART' are not 4830 in this class, but in class `x'. 4831 4832`<' 4833 An RTX code for a comparison, such as `NE' or `LT'. 4834 4835`1' 4836 An RTX code for a unary arithmetic operation, such as `NEG', 4837 `NOT', or `ABS'. This category also includes value extension 4838 (sign or zero) and conversions between integer and floating point. 4839 4840`c' 4841 An RTX code for a commutative binary operation, such as `PLUS' or 4842 `AND'. `NE' and `EQ' are comparisons, so they have class `<'. 4843 4844`2' 4845 An RTX code for a non-commutative binary operation, such as 4846 `MINUS', `DIV', or `ASHIFTRT'. 4847 4848`b' 4849 An RTX code for a bit-field operation. Currently only 4850 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and 4851 are lvalues (so they can be used for insertion as well). *Note 4852 Bit-Fields::. 4853 4854`3' 4855 An RTX code for other three input operations. Currently only 4856 `IF_THEN_ELSE'. 4857 4858`i' 4859 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and 4860 `CALL_INSN'. *Note Insns::. 4861 4862`m' 4863 An RTX code for something that matches in insns, such as 4864 `MATCH_DUP'. These only occur in machine descriptions. 4865 4866`a' 4867 An RTX code for an auto-increment addressing mode, such as 4868 `POST_INC'. 4869 4870`x' 4871 All other RTX codes. This category includes the remaining codes 4872 used only in machine descriptions (`DEFINE_*', etc.). It also 4873 includes all the codes describing side effects (`SET', `USE', 4874 `CLOBBER', etc.) and the non-insns that may appear on an insn 4875 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. 4876 4877 For each expression code, `rtl.def' specifies the number of 4878contained objects and their kinds using a sequence of characters called 4879the "format" of the expression code. For example, the format of 4880`subreg' is `ei'. 4881 4882 These are the most commonly used format characters: 4883 4884`e' 4885 An expression (actually a pointer to an expression). 4886 4887`i' 4888 An integer. 4889 4890`w' 4891 A wide integer. 4892 4893`s' 4894 A string. 4895 4896`E' 4897 A vector of expressions. 4898 4899 A few other format characters are used occasionally: 4900 4901`u' 4902 `u' is equivalent to `e' except that it is printed differently in 4903 debugging dumps. It is used for pointers to insns. 4904 4905`n' 4906 `n' is equivalent to `i' except that it is printed differently in 4907 debugging dumps. It is used for the line number or code number of 4908 a `note' insn. 4909 4910`S' 4911 `S' indicates a string which is optional. In the RTL objects in 4912 core, `S' is equivalent to `s', but when the object is read, from 4913 an `md' file, the string value of this operand may be omitted. An 4914 omitted string is taken to be the null string. 4915 4916`V' 4917 `V' indicates a vector which is optional. In the RTL objects in 4918 core, `V' is equivalent to `E', but when the object is read from 4919 an `md' file, the vector value of this operand may be omitted. An 4920 omitted vector is effectively the same as a vector of no elements. 4921 4922`B' 4923 `B' indicates a pointer to basic block structure. 4924 4925`0' 4926 `0' means a slot whose contents do not fit any normal category. 4927 `0' slots are not printed at all in dumps, and are often used in 4928 special ways by small parts of the compiler. 4929 4930 There are macros to get the number of operands and the format of an 4931expression code: 4932 4933`GET_RTX_LENGTH (CODE)' 4934 Number of operands of an RTX of code CODE. 4935 4936`GET_RTX_FORMAT (CODE)' 4937 The format of an RTX of code CODE, as a C string. 4938 4939 Some classes of RTX codes always have the same format. For example, 4940it is safe to assume that all comparison operations have format `ee'. 4941 4942`1' 4943 All codes of this class have format `e'. 4944 4945`<' 4946`c' 4947`2' 4948 All codes of these classes have format `ee'. 4949 4950`b' 4951`3' 4952 All codes of these classes have format `eee'. 4953 4954`i' 4955 All codes of this class have formats that begin with `iuueiee'. 4956 *Note Insns::. Note that not all RTL objects linked onto an insn 4957 chain are of class `i'. 4958 4959`o' 4960`m' 4961`x' 4962 You can make no assumptions about the format of these codes. 4963 4964 4965File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 4966 49679.3 Access to Operands 4968====================== 4969 4970Operands of expressions are accessed using the macros `XEXP', `XINT', 4971`XWINT' and `XSTR'. Each of these macros takes two arguments: an 4972expression-pointer (RTX) and an operand number (counting from zero). 4973Thus, 4974 4975 XEXP (X, 2) 4976 4977accesses operand 2 of expression X, as an expression. 4978 4979 XINT (X, 2) 4980 4981accesses the same operand as an integer. `XSTR', used in the same 4982fashion, would access it as a string. 4983 4984 Any operand can be accessed as an integer, as an expression or as a 4985string. You must choose the correct method of access for the kind of 4986value actually stored in the operand. You would do this based on the 4987expression code of the containing expression. That is also how you 4988would know how many operands there are. 4989 4990 For example, if X is a `subreg' expression, you know that it has two 4991operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, 49921)'. If you did `XINT (X, 0)', you would get the address of the 4993expression operand but cast as an integer; that might occasionally be 4994useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP 4995(X, 1)' would also compile without error, and would return the second, 4996integer operand cast as an expression pointer, which would probably 4997result in a crash when accessed. Nothing stops you from writing `XEXP 4998(X, 28)' either, but this will access memory past the end of the 4999expression with unpredictable results. 5000 5001 Access to operands which are vectors is more complicated. You can 5002use the macro `XVEC' to get the vector-pointer itself, or the macros 5003`XVECEXP' and `XVECLEN' to access the elements and length of a vector. 5004 5005`XVEC (EXP, IDX)' 5006 Access the vector-pointer which is operand number IDX in EXP. 5007 5008`XVECLEN (EXP, IDX)' 5009 Access the length (number of elements) in the vector which is in 5010 operand number IDX in EXP. This value is an `int'. 5011 5012`XVECEXP (EXP, IDX, ELTNUM)' 5013 Access element number ELTNUM in the vector which is in operand 5014 number IDX in EXP. This value is an RTX. 5015 5016 It is up to you to make sure that ELTNUM is not negative and is 5017 less than `XVECLEN (EXP, IDX)'. 5018 5019 All the macros defined in this section expand into lvalues and 5020therefore can be used to assign the operands, lengths and vector 5021elements as well as to access them. 5022 5023 5024File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 5025 50269.4 Access to Special Operands 5027============================== 5028 5029Some RTL nodes have special annotations associated with them. 5030 5031`MEM' 5032 5033 `MEM_ALIAS_SET (X)' 5034 If 0, X is not in any alias set, and may alias anything. 5035 Otherwise, X can only alias `MEM's in a conflicting alias 5036 set. This value is set in a language-dependent manner in the 5037 front-end, and should not be altered in the back-end. In 5038 some front-ends, these numbers may correspond in some way to 5039 types, or other language-level entities, but they need not, 5040 and the back-end makes no such assumptions. These set 5041 numbers are tested with `alias_sets_conflict_p'. 5042 5043 `MEM_EXPR (X)' 5044 If this register is known to hold the value of some user-level 5045 declaration, this is that tree node. It may also be a 5046 `COMPONENT_REF', in which case this is some field reference, 5047 and `TREE_OPERAND (X, 0)' contains the declaration, or 5048 another `COMPONENT_REF', or null if there is no compile-time 5049 object associated with the reference. 5050 5051 `MEM_OFFSET (X)' 5052 The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx. 5053 5054 `MEM_SIZE (X)' 5055 The size in bytes of the memory reference as a `CONST_INT' 5056 rtx. This is mostly relevant for `BLKmode' references as 5057 otherwise the size is implied by the mode. 5058 5059 `MEM_ALIGN (X)' 5060 The known alignment in bits of the memory reference. 5061 5062`REG' 5063 5064 `ORIGINAL_REGNO (X)' 5065 This field holds the number the register "originally" had; 5066 for a pseudo register turned into a hard reg this will hold 5067 the old pseudo register number. 5068 5069 `REG_EXPR (X)' 5070 If this register is known to hold the value of some user-level 5071 declaration, this is that tree node. 5072 5073 `REG_OFFSET (X)' 5074 If this register is known to hold the value of some user-level 5075 declaration, this is the offset into that logical storage. 5076 5077`SYMBOL_REF' 5078 5079 `SYMBOL_REF_DECL (X)' 5080 If the `symbol_ref' X was created for a `VAR_DECL' or a 5081 `FUNCTION_DECL', that tree is recorded here. If this value is 5082 null, then X was created by back end code generation routines, 5083 and there is no associated front end symbol table entry. 5084 5085 `SYMBOL_REF_DECL' may also point to a tree of class `'c'', 5086 that is, some sort of constant. In this case, the 5087 `symbol_ref' is an entry in the per-file constant pool; 5088 again, there is no associated front end symbol table entry. 5089 5090 `SYMBOL_REF_FLAGS (X)' 5091 In a `symbol_ref', this is used to communicate various 5092 predicates about the symbol. Some of these are common enough 5093 to be computed by common code, some are specific to the 5094 target. The common bits are: 5095 5096 `SYMBOL_FLAG_FUNCTION' 5097 Set if the symbol refers to a function. 5098 5099 `SYMBOL_FLAG_LOCAL' 5100 Set if the symbol is local to this "module". See 5101 `TARGET_BINDS_LOCAL_P'. 5102 5103 `SYMBOL_FLAG_EXTERNAL' 5104 Set if this symbol is not defined in this translation 5105 unit. Note that this is not the inverse of 5106 `SYMBOL_FLAG_LOCAL'. 5107 5108 `SYMBOL_FLAG_SMALL' 5109 Set if the symbol is located in the small data section. 5110 See `TARGET_IN_SMALL_DATA_P'. 5111 5112 `SYMBOL_REF_TLS_MODEL (X)' 5113 This is a multi-bit field accessor that returns the 5114 `tls_model' to be used for a thread-local storage 5115 symbol. It returns zero for non-thread-local symbols. 5116 5117 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for 5118 the target's use. 5119 5120 5121File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 5122 51239.5 Flags in an RTL Expression 5124============================== 5125 5126RTL expressions contain several flags (one-bit bit-fields) that are 5127used in certain types of expression. Most often they are accessed with 5128the following macros, which expand into lvalues. 5129 5130`CONSTANT_POOL_ADDRESS_P (X)' 5131 Nonzero in a `symbol_ref' if it refers to part of the current 5132 function's constant pool. For most targets these addresses are in 5133 a `.rodata' section entirely separate from the function, but for 5134 some targets the addresses are close to the beginning of the 5135 function. In either case GCC assumes these addresses can be 5136 addressed directly, perhaps with the help of base registers. 5137 Stored in the `unchanging' field and printed as `/u'. 5138 5139`CONST_OR_PURE_CALL_P (X)' 5140 In a `call_insn', `note', or an `expr_list' for notes, indicates 5141 that the insn represents a call to a const or pure function. 5142 Stored in the `unchanging' field and printed as `/u'. 5143 5144`INSN_ANNULLED_BRANCH_P (X)' 5145 In a `jump_insn', `call_insn', or `insn' indicates that the branch 5146 is an annulling one. See the discussion under `sequence' below. 5147 Stored in the `unchanging' field and printed as `/u'. 5148 5149`INSN_DEAD_CODE_P (X)' 5150 In an `insn' during the dead-code elimination pass, nonzero if the 5151 insn is dead. Stored in the `in_struct' field and printed as `/s'. 5152 5153`INSN_DELETED_P (X)' 5154 In an `insn', `call_insn', `jump_insn', `code_label', `barrier', 5155 or `note', nonzero if the insn has been deleted. Stored in the 5156 `volatil' field and printed as `/v'. 5157 5158`INSN_FROM_TARGET_P (X)' 5159 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a 5160 branch, indicates that the insn is from the target of the branch. 5161 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn 5162 will only be executed if the branch is taken. For annulled 5163 branches with `INSN_FROM_TARGET_P' clear, the insn will be 5164 executed only if the branch is not taken. When 5165 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be 5166 executed. Stored in the `in_struct' field and printed as `/s'. 5167 5168`LABEL_OUTSIDE_LOOP_P (X)' 5169 In `label_ref' expressions, nonzero if this is a reference to a 5170 label that is outside the innermost loop containing the reference 5171 to the label. Stored in the `in_struct' field and printed as `/s'. 5172 5173`LABEL_PRESERVE_P (X)' 5174 In a `code_label' or `note', indicates that the label is 5175 referenced by code or data not visible to the RTL of a given 5176 function. Labels referenced by a non-local goto will have this 5177 bit set. Stored in the `in_struct' field and printed as `/s'. 5178 5179`LABEL_REF_NONLOCAL_P (X)' 5180 In `label_ref' and `reg_label' expressions, nonzero if this is a 5181 reference to a non-local label. Stored in the `volatil' field and 5182 printed as `/v'. 5183 5184`MEM_IN_STRUCT_P (X)' 5185 In `mem' expressions, nonzero for reference to an entire structure, 5186 union or array, or to a component of one. Zero for references to a 5187 scalar variable or through a pointer to a scalar. If both this 5188 flag and `MEM_SCALAR_P' are clear, then we don't know whether this 5189 `mem' is in a structure or not. Both flags should never be 5190 simultaneously set. Stored in the `in_struct' field and printed 5191 as `/s'. 5192 5193`MEM_KEEP_ALIAS_SET_P (X)' 5194 In `mem' expressions, 1 if we should keep the alias set for this 5195 mem unchanged when we access a component. Set to 1, for example, 5196 when we are already in a non-addressable component of an aggregate. 5197 Stored in the `jump' field and printed as `/j'. 5198 5199`MEM_SCALAR_P (X)' 5200 In `mem' expressions, nonzero for reference to a scalar known not 5201 to be a member of a structure, union, or array. Zero for such 5202 references and for indirections through pointers, even pointers 5203 pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P' 5204 are clear, then we don't know whether this `mem' is in a structure 5205 or not. Both flags should never be simultaneously set. Stored in 5206 the `frame_related' field and printed as `/f'. 5207 5208`MEM_VOLATILE_P (X)' 5209 In `mem', `asm_operands', and `asm_input' expressions, nonzero for 5210 volatile memory references. Stored in the `volatil' field and 5211 printed as `/v'. 5212 5213`MEM_NOTRAP_P (X)' 5214 In `mem', nonzero for memory references that will not trap. 5215 Stored in the `call' field and printed as `/c'. 5216 5217`REG_FUNCTION_VALUE_P (X)' 5218 Nonzero in a `reg' if it is the place in which this function's 5219 value is going to be returned. (This happens only in a hard 5220 register.) Stored in the `integrated' field and printed as `/i'. 5221 5222`REG_LOOP_TEST_P (X)' 5223 In `reg' expressions, nonzero if this register's entire life is 5224 contained in the exit test code for some loop. Stored in the 5225 `in_struct' field and printed as `/s'. 5226 5227`REG_POINTER (X)' 5228 Nonzero in a `reg' if the register holds a pointer. Stored in the 5229 `frame_related' field and printed as `/f'. 5230 5231`REG_USERVAR_P (X)' 5232 In a `reg', nonzero if it corresponds to a variable present in the 5233 user's source code. Zero for temporaries generated internally by 5234 the compiler. Stored in the `volatil' field and printed as `/v'. 5235 5236 The same hard register may be used also for collecting the values 5237 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero 5238 in this kind of use. 5239 5240`RTX_FRAME_RELATED_P (X)' 5241 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or 5242 `set' which is part of a function prologue and sets the stack 5243 pointer, sets the frame pointer, or saves a register. This flag 5244 should also be set on an instruction that sets up a temporary 5245 register to use in place of the frame pointer. Stored in the 5246 `frame_related' field and printed as `/f'. 5247 5248 In particular, on RISC targets where there are limits on the sizes 5249 of immediate constants, it is sometimes impossible to reach the 5250 register save area directly from the stack pointer. In that case, 5251 a temporary register is used that is near enough to the register 5252 save area, and the Canonical Frame Address, i.e., DWARF2's logical 5253 frame pointer, register must (temporarily) be changed to be this 5254 temporary register. So, the instruction that sets this temporary 5255 register must be marked as `RTX_FRAME_RELATED_P'. 5256 5257 If the marked instruction is overly complex (defined in terms of 5258 what `dwarf2out_frame_debug_expr' can handle), you will also have 5259 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the 5260 instruction. This note should contain a simple expression of the 5261 computation performed by this instruction, i.e., one that 5262 `dwarf2out_frame_debug_expr' can handle. 5263 5264 This flag is required for exception handling support on targets 5265 with RTL prologues. 5266 5267`RTX_INTEGRATED_P (X)' 5268 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', 5269 `code_label', `insn_list', `const', or `note' if it resulted from 5270 an in-line function call. Stored in the `integrated' field and 5271 printed as `/i'. 5272 5273`RTX_UNCHANGING_P (X)' 5274 Nonzero in a `reg', `mem', or `concat' if the register or memory 5275 is set at most once, anywhere. This does not mean that it is 5276 function invariant. 5277 5278 GCC uses this flag to determine whether two references conflict. 5279 As implemented by `true_dependence' in `alias.c' for memory 5280 references, unchanging memory can't conflict with non-unchanging 5281 memory; a non-unchanging read can conflict with a non-unchanging 5282 write; an unchanging read can conflict with an unchanging write 5283 (since there may be a single store to this address to initialize 5284 it); and an unchanging store can conflict with a non-unchanging 5285 read. This means we must make conservative assumptions when 5286 choosing the value of this flag for a memory reference to an 5287 object containing both unchanging and non-unchanging fields: we 5288 must set the flag when writing to the object and clear it when 5289 reading from the object. 5290 5291 Stored in the `unchanging' field and printed as `/u'. 5292 5293`SCHED_GROUP_P (X)' 5294 During instruction scheduling, in an `insn', `call_insn' or 5295 `jump_insn', indicates that the previous insn must be scheduled 5296 together with this insn. This is used to ensure that certain 5297 groups of instructions will not be split up by the instruction 5298 scheduling pass, for example, `use' insns before a `call_insn' may 5299 not be separated from the `call_insn'. Stored in the `in_struct' 5300 field and printed as `/s'. 5301 5302`SET_IS_RETURN_P (X)' 5303 For a `set', nonzero if it is for a return. Stored in the `jump' 5304 field and printed as `/j'. 5305 5306`SIBLING_CALL_P (X)' 5307 For a `call_insn', nonzero if the insn is a sibling call. Stored 5308 in the `jump' field and printed as `/j'. 5309 5310`STRING_POOL_ADDRESS_P (X)' 5311 For a `symbol_ref' expression, nonzero if it addresses this 5312 function's string constant pool. Stored in the `frame_related' 5313 field and printed as `/f'. 5314 5315`SUBREG_PROMOTED_UNSIGNED_P (X)' 5316 Returns a value greater then zero for a `subreg' that has 5317 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 5318 kept zero-extended, zero if it is kept sign-extended, and less 5319 then zero if it is extended some other way via the `ptr_extend' 5320 instruction. Stored in the `unchanging' field and `volatil' 5321 field, printed as `/u' and `/v'. This macro may only be used to 5322 get the value it may not be used to change the value. Use 5323 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 5324 5325`SUBREG_PROMOTED_UNSIGNED_SET (X)' 5326 Set the `unchanging' and `volatil' fields in a `subreg' to reflect 5327 zero, sign, or other extension. If `volatil' is zero, then 5328 `unchanging' as nonzero means zero extension and as zero means 5329 sign extension. If `volatil' is nonzero then some other type of 5330 extension was done via the `ptr_extend' instruction. 5331 5332`SUBREG_PROMOTED_VAR_P (X)' 5333 Nonzero in a `subreg' if it was made when accessing an object that 5334 was promoted to a wider mode in accord with the `PROMOTED_MODE' 5335 machine description macro (*note Storage Layout::). In this case, 5336 the mode of the `subreg' is the declared mode of the object and 5337 the mode of `SUBREG_REG' is the mode of the register that holds 5338 the object. Promoted variables are always either sign- or 5339 zero-extended to the wider mode on every assignment. Stored in 5340 the `in_struct' field and printed as `/s'. 5341 5342`SYMBOL_REF_USED (X)' 5343 In a `symbol_ref', indicates that X has been used. This is 5344 normally only used to ensure that X is only declared external 5345 once. Stored in the `used' field. 5346 5347`SYMBOL_REF_WEAK (X)' 5348 In a `symbol_ref', indicates that X has been declared weak. 5349 Stored in the `integrated' field and printed as `/i'. 5350 5351`SYMBOL_REF_FLAG (X)' 5352 In a `symbol_ref', this is used as a flag for machine-specific 5353 purposes. Stored in the `volatil' field and printed as `/v'. 5354 5355 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by 5356 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is 5357 mandatory if the target requires more than one bit of storage. 5358 5359 These are the fields to which the above macros refer: 5360 5361`call' 5362 In a `mem', 1 means that the memory reference will not trap. 5363 5364 In an RTL dump, this flag is represented as `/c'. 5365 5366`frame_related' 5367 In an `insn' or `set' expression, 1 means that it is part of a 5368 function prologue and sets the stack pointer, sets the frame 5369 pointer, saves a register, or sets up a temporary register to use 5370 in place of the frame pointer. 5371 5372 In `reg' expressions, 1 means that the register holds a pointer. 5373 5374 In `symbol_ref' expressions, 1 means that the reference addresses 5375 this function's string constant pool. 5376 5377 In `mem' expressions, 1 means that the reference is to a scalar. 5378 5379 In an RTL dump, this flag is represented as `/f'. 5380 5381`in_struct' 5382 In `mem' expressions, it is 1 if the memory datum referred to is 5383 all or part of a structure or array; 0 if it is (or might be) a 5384 scalar variable. A reference through a C pointer has 0 because 5385 the pointer might point to a scalar variable. This information 5386 allows the compiler to determine something about possible cases of 5387 aliasing. 5388 5389 In `reg' expressions, it is 1 if the register has its entire life 5390 contained within the test expression of some loop. 5391 5392 In `subreg' expressions, 1 means that the `subreg' is accessing an 5393 object that has had its mode promoted from a wider mode. 5394 5395 In `label_ref' expressions, 1 means that the referenced label is 5396 outside the innermost loop containing the insn in which the 5397 `label_ref' was found. 5398 5399 In `code_label' expressions, it is 1 if the label may never be 5400 deleted. This is used for labels which are the target of 5401 non-local gotos. Such a label that would have been deleted is 5402 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'. 5403 5404 In an `insn' during dead-code elimination, 1 means that the insn is 5405 dead code. 5406 5407 In an `insn' or `jump_insn' during reorg for an insn in the delay 5408 slot of a branch, 1 means that this insn is from the target of the 5409 branch. 5410 5411 In an `insn' during instruction scheduling, 1 means that this insn 5412 must be scheduled as part of a group together with the previous 5413 insn. 5414 5415 In an RTL dump, this flag is represented as `/s'. 5416 5417`integrated' 5418 In an `insn', `insn_list', or `const', 1 means the RTL was 5419 produced by procedure integration. 5420 5421 In `reg' expressions, 1 means the register contains the value to 5422 be returned by the current function. On machines that pass 5423 parameters in registers, the same register number may be used for 5424 parameters as well, but this flag is not set on such uses. 5425 5426 In `symbol_ref' expressions, 1 means the referenced symbol is weak. 5427 5428 In an RTL dump, this flag is represented as `/i'. 5429 5430`jump' 5431 In a `mem' expression, 1 means we should keep the alias set for 5432 this mem unchanged when we access a component. 5433 5434 In a `set', 1 means it is for a return. 5435 5436 In a `call_insn', 1 means it is a sibling call. 5437 5438 In an RTL dump, this flag is represented as `/j'. 5439 5440`unchanging' 5441 In `reg' and `mem' expressions, 1 means that the value of the 5442 expression never changes. 5443 5444 In `subreg' expressions, it is 1 if the `subreg' references an 5445 unsigned object whose mode has been promoted to a wider mode. 5446 5447 In an `insn' or `jump_insn' in the delay slot of a branch 5448 instruction, 1 means an annulling branch should be used. 5449 5450 In a `symbol_ref' expression, 1 means that this symbol addresses 5451 something in the per-function constant pool. 5452 5453 In a `call_insn', `note', or an `expr_list' of notes, 1 means that 5454 this instruction is a call to a const or pure function. 5455 5456 In an RTL dump, this flag is represented as `/u'. 5457 5458`used' 5459 This flag is used directly (without an access macro) at the end of 5460 RTL generation for a function, to count the number of times an 5461 expression appears in insns. Expressions that appear more than 5462 once are copied, according to the rules for shared structure 5463 (*note Sharing::). 5464 5465 For a `reg', it is used directly (without an access macro) by the 5466 leaf register renumbering code to ensure that each register is only 5467 renumbered once. 5468 5469 In a `symbol_ref', it indicates that an external declaration for 5470 the symbol has already been written. 5471 5472`volatil' 5473 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if 5474 the memory reference is volatile. Volatile memory references may 5475 not be deleted, reordered or combined. 5476 5477 In a `symbol_ref' expression, it is used for machine-specific 5478 purposes. 5479 5480 In a `reg' expression, it is 1 if the value is a user-level 5481 variable. 0 indicates an internal compiler temporary. 5482 5483 In an `insn', 1 means the insn has been deleted. 5484 5485 In `label_ref' and `reg_label' expressions, 1 means a reference to 5486 a non-local label. 5487 5488 In an RTL dump, this flag is represented as `/v'. 5489 5490 5491File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 5492 54939.6 Machine Modes 5494================= 5495 5496A machine mode describes a size of data object and the representation 5497used for it. In the C code, machine modes are represented by an 5498enumeration type, `enum machine_mode', defined in `machmode.def'. Each 5499RTL expression has room for a machine mode and so do certain kinds of 5500tree expressions (declarations and types, to be precise). 5501 5502 In debugging dumps and machine descriptions, the machine mode of an 5503RTL expression is written after the expression code with a colon to 5504separate them. The letters `mode' which appear at the end of each 5505machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' 5506expression with machine mode `SImode'. If the mode is `VOIDmode', it 5507is not written at all. 5508 5509 Here is a table of machine modes. The term "byte" below refers to an 5510object of `BITS_PER_UNIT' bits (*note Storage Layout::). 5511 5512`BImode' 5513 "Bit" mode represents a single bit, for predicate registers. 5514 5515`QImode' 5516 "Quarter-Integer" mode represents a single byte treated as an 5517 integer. 5518 5519`HImode' 5520 "Half-Integer" mode represents a two-byte integer. 5521 5522`PSImode' 5523 "Partial Single Integer" mode represents an integer which occupies 5524 four bytes but which doesn't really use all four. On some 5525 machines, this is the right mode to use for pointers. 5526 5527`SImode' 5528 "Single Integer" mode represents a four-byte integer. 5529 5530`PDImode' 5531 "Partial Double Integer" mode represents an integer which occupies 5532 eight bytes but which doesn't really use all eight. On some 5533 machines, this is the right mode to use for certain pointers. 5534 5535`DImode' 5536 "Double Integer" mode represents an eight-byte integer. 5537 5538`TImode' 5539 "Tetra Integer" (?) mode represents a sixteen-byte integer. 5540 5541`OImode' 5542 "Octa Integer" (?) mode represents a thirty-two-byte integer. 5543 5544`QFmode' 5545 "Quarter-Floating" mode represents a quarter-precision (single 5546 byte) floating point number. 5547 5548`HFmode' 5549 "Half-Floating" mode represents a half-precision (two byte) 5550 floating point number. 5551 5552`TQFmode' 5553 "Three-Quarter-Floating" (?) mode represents a 5554 three-quarter-precision (three byte) floating point number. 5555 5556`SFmode' 5557 "Single Floating" mode represents a four byte floating point 5558 number. In the common case, of a processor with IEEE arithmetic 5559 and 8-bit bytes, this is a single-precision IEEE floating point 5560 number; it can also be used for double-precision (on processors 5561 with 16-bit bytes) and single-precision VAX and IBM types. 5562 5563`DFmode' 5564 "Double Floating" mode represents an eight byte floating point 5565 number. In the common case, of a processor with IEEE arithmetic 5566 and 8-bit bytes, this is a double-precision IEEE floating point 5567 number. 5568 5569`XFmode' 5570 "Extended Floating" mode represents a twelve byte floating point 5571 number. This mode is used for IEEE extended floating point. On 5572 some systems not all bits within these bytes will actually be used. 5573 5574`TFmode' 5575 "Tetra Floating" mode represents a sixteen byte floating point 5576 number. This gets used for both the 96-bit extended IEEE 5577 floating-point types padded to 128 bits, and true 128-bit extended 5578 IEEE floating-point types. 5579 5580`CCmode' 5581 "Condition Code" mode represents the value of a condition code, 5582 which is a machine-specific set of bits used to represent the 5583 result of a comparison operation. Other machine-specific modes 5584 may also be used for the condition code. These modes are not used 5585 on machines that use `cc0' (see *note Condition Code::). 5586 5587`BLKmode' 5588 "Block" mode represents values that are aggregates to which none of 5589 the other modes apply. In RTL, only memory references can have 5590 this mode, and only if they appear in string-move or vector 5591 instructions. On machines which have no such instructions, 5592 `BLKmode' will not appear in RTL. 5593 5594`VOIDmode' 5595 Void mode means the absence of a mode or an unspecified mode. For 5596 example, RTL expressions of code `const_int' have mode `VOIDmode' 5597 because they can be taken to have whatever mode the context 5598 requires. In debugging dumps of RTL, `VOIDmode' is expressed by 5599 the absence of any mode. 5600 5601`QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 5602 These modes stand for a complex number represented as a pair of 5603 floating point values. The floating point values are in `QFmode', 5604 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively. 5605 5606`CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 5607 These modes stand for a complex number represented as a pair of 5608 integer values. The integer values are in `QImode', `HImode', 5609 `SImode', `DImode', `TImode', and `OImode', respectively. 5610 5611 The machine description defines `Pmode' as a C macro which expands 5612into the machine mode used for addresses. Normally this is the mode 5613whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 5614 5615 The only modes which a machine description must support are 5616`QImode', and the modes corresponding to `BITS_PER_WORD', 5617`FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to 5618use `DImode' for 8-byte structures and unions, but this can be 5619prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. 5620Alternatively, you can have the compiler use `TImode' for 16-byte 5621structures and unions. Likewise, you can arrange for the C type `short 5622int' to avoid using `HImode'. 5623 5624 Very few explicit references to machine modes remain in the compiler 5625and these few references will soon be removed. Instead, the machine 5626modes are divided into mode classes. These are represented by the 5627enumeration type `enum mode_class' defined in `machmode.h'. The 5628possible mode classes are: 5629 5630`MODE_INT' 5631 Integer modes. By default these are `BImode', `QImode', `HImode', 5632 `SImode', `DImode', `TImode', and `OImode'. 5633 5634`MODE_PARTIAL_INT' 5635 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and 5636 `PDImode'. 5637 5638`MODE_FLOAT' 5639 Floating point modes. By default these are `QFmode', `HFmode', 5640 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'. 5641 5642`MODE_COMPLEX_INT' 5643 Complex integer modes. (These are not currently implemented). 5644 5645`MODE_COMPLEX_FLOAT' 5646 Complex floating point modes. By default these are `QCmode', 5647 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'. 5648 5649`MODE_FUNCTION' 5650 Algol or Pascal function variables including a static chain. 5651 (These are not currently implemented). 5652 5653`MODE_CC' 5654 Modes representing condition code values. These are `CCmode' plus 5655 any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump 5656 Patterns::, also see *Note Condition Code::. 5657 5658`MODE_RANDOM' 5659 This is a catchall mode class for modes which don't fit into the 5660 above classes. Currently `VOIDmode' and `BLKmode' are in 5661 `MODE_RANDOM'. 5662 5663 Here are some C macros that relate to machine modes: 5664 5665`GET_MODE (X)' 5666 Returns the machine mode of the RTX X. 5667 5668`PUT_MODE (X, NEWMODE)' 5669 Alters the machine mode of the RTX X to be NEWMODE. 5670 5671`NUM_MACHINE_MODES' 5672 Stands for the number of machine modes available on the target 5673 machine. This is one greater than the largest numeric value of any 5674 machine mode. 5675 5676`GET_MODE_NAME (M)' 5677 Returns the name of mode M as a string. 5678 5679`GET_MODE_CLASS (M)' 5680 Returns the mode class of mode M. 5681 5682`GET_MODE_WIDER_MODE (M)' 5683 Returns the next wider natural mode. For example, the expression 5684 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 5685 5686`GET_MODE_SIZE (M)' 5687 Returns the size in bytes of a datum of mode M. 5688 5689`GET_MODE_BITSIZE (M)' 5690 Returns the size in bits of a datum of mode M. 5691 5692`GET_MODE_MASK (M)' 5693 Returns a bitmask containing 1 for all bits in a word that fit 5694 within mode M. This macro can only be used for modes whose 5695 bitsize is less than or equal to `HOST_BITS_PER_INT'. 5696 5697`GET_MODE_ALIGNMENT (M)' 5698 Return the required alignment, in bits, for an object of mode M. 5699 5700`GET_MODE_UNIT_SIZE (M)' 5701 Returns the size in bytes of the subunits of a datum of mode M. 5702 This is the same as `GET_MODE_SIZE' except in the case of complex 5703 modes. For them, the unit size is the size of the real or 5704 imaginary part. 5705 5706`GET_MODE_NUNITS (M)' 5707 Returns the number of units contained in a mode, i.e., 5708 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 5709 5710`GET_CLASS_NARROWEST_MODE (C)' 5711 Returns the narrowest mode in mode class C. 5712 5713 The global variables `byte_mode' and `word_mode' contain modes whose 5714classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 5715`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 5716and `SImode', respectively. 5717 5718 5719File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 5720 57219.7 Constant Expression Types 5722============================= 5723 5724The simplest RTL expressions are those that represent constant values. 5725 5726`(const_int I)' 5727 This type of expression represents the integer value I. I is 5728 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 5729 which is equivalent to `XWINT (EXP, 0)'. 5730 5731 There is only one expression object for the integer value zero; it 5732 is the value of the variable `const0_rtx'. Likewise, the only 5733 expression for integer value one is found in `const1_rtx', the only 5734 expression for integer value two is found in `const2_rtx', and the 5735 only expression for integer value negative one is found in 5736 `constm1_rtx'. Any attempt to create an expression of code 5737 `const_int' and value zero, one, two or negative one will return 5738 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 5739 appropriate. 5740 5741 Similarly, there is only one object for the integer whose value is 5742 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 5743 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 5744 point to the same object. If `STORE_FLAG_VALUE' is -1, 5745 `const_true_rtx' and `constm1_rtx' will point to the same object. 5746 5747`(const_double:M ADDR I0 I1 ...)' 5748 Represents either a floating-point constant of mode M or an 5749 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 5750 bits but small enough to fit within twice that number of bits (GCC 5751 does not provide a mechanism to represent even larger constants). 5752 In the latter case, M will be `VOIDmode'. 5753 5754`(const_vector:M [X0 X1 ...])' 5755 Represents a vector constant. The square brackets stand for the 5756 vector containing the constant elements. X0, X1 and so on are the 5757 `const_int' or `const_double' elements. 5758 5759 The number of units in a `const_vector' is obtained with the macro 5760 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'. 5761 5762 Individual elements in a vector constant are accessed with the 5763 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V 5764 is the vector constant and N is the element desired. 5765 5766 ADDR is used to contain the `mem' expression that corresponds to 5767 the location in memory that at which the constant can be found. If 5768 it has not been allocated a memory location, but is on the chain 5769 of all `const_double' expressions in this compilation (maintained 5770 using an undisplayed field), ADDR contains `const0_rtx'. If it is 5771 not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily 5772 accessed with the macro `CONST_DOUBLE_MEM' and the chain field via 5773 `CONST_DOUBLE_CHAIN'. 5774 5775 If M is `VOIDmode', the bits of the value are stored in I0 and I1. 5776 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 5777 I1 with `CONST_DOUBLE_HIGH'. 5778 5779 If the constant is floating point (regardless of its precision), 5780 then the number of integers used to store the value depends on the 5781 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers 5782 represent a floating point number, but not precisely in the target 5783 machine's or host machine's floating point format. To convert 5784 them to the precise bit pattern used by the target machine, use 5785 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 5786 Output::). 5787 5788 The macro `CONST0_RTX (MODE)' refers to an expression with value 0 5789 in mode MODE. If mode MODE is of mode class `MODE_INT', it 5790 returns `const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', 5791 it returns a `CONST_DOUBLE' expression in mode MODE. Otherwise, 5792 it returns a `CONST_VECTOR' expression in mode MODE. Similarly, 5793 the macro `CONST1_RTX (MODE)' refers to an expression with value 1 5794 in mode MODE and similarly for `CONST2_RTX'. The `CONST1_RTX' and 5795 `CONST2_RTX' macros are undefined for vector modes. 5796 5797`(const_string STR)' 5798 Represents a constant string with value STR. Currently this is 5799 used only for insn attributes (*note Insn Attributes::) since 5800 constant strings in C are placed in memory. 5801 5802`(symbol_ref:MODE SYMBOL)' 5803 Represents the value of an assembler label for data. SYMBOL is a 5804 string that describes the name of the assembler label. If it 5805 starts with a `*', the label is the rest of SYMBOL not including 5806 the `*'. Otherwise, the label is SYMBOL, usually prefixed with 5807 `_'. 5808 5809 The `symbol_ref' contains a mode, which is usually `Pmode'. 5810 Usually that is the only mode for which a symbol is directly valid. 5811 5812`(label_ref LABEL)' 5813 Represents the value of an assembler label for code. It contains 5814 one operand, an expression, which must be a `code_label' or a 5815 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the 5816 instruction sequence to identify the place where the label should 5817 go. 5818 5819 The reason for using a distinct expression type for code label 5820 references is so that jump optimization can distinguish them. 5821 5822`(const:M EXP)' 5823 Represents a constant that is the result of an assembly-time 5824 arithmetic computation. The operand, EXP, is an expression that 5825 contains only constants (`const_int', `symbol_ref' and `label_ref' 5826 expressions) combined with `plus' and `minus'. However, not all 5827 combinations are valid, since the assembler cannot do arbitrary 5828 arithmetic on relocatable symbols. 5829 5830 M should be `Pmode'. 5831 5832`(high:M EXP)' 5833 Represents the high-order bits of EXP, usually a `symbol_ref'. 5834 The number of bits is machine-dependent and is normally the number 5835 of bits specified in an instruction that initializes the high 5836 order bits of a register. It is used with `lo_sum' to represent 5837 the typical two-instruction sequence used in RISC machines to 5838 reference a global memory location. 5839 5840 M should be `Pmode'. 5841 5842 5843File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 5844 58459.8 Registers and Memory 5846======================== 5847 5848Here are the RTL expression types for describing access to machine 5849registers and to main memory. 5850 5851`(reg:M N)' 5852 For small values of the integer N (those that are less than 5853 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 5854 register number N: a "hard register". For larger values of N, it 5855 stands for a temporary value or "pseudo register". The compiler's 5856 strategy is to generate code assuming an unlimited number of such 5857 pseudo registers, and later convert them into hard registers or 5858 into memory references. 5859 5860 M is the machine mode of the reference. It is necessary because 5861 machines can generally refer to each register in more than one 5862 mode. For example, a register may contain a full word but there 5863 may be instructions to refer to it as a half word or as a single 5864 byte, as well as instructions to refer to it as a floating point 5865 number of various precisions. 5866 5867 Even for a register that the machine can access in only one mode, 5868 the mode must always be specified. 5869 5870 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 5871 description, since the number of hard registers on the machine is 5872 an invariant characteristic of the machine. Note, however, that 5873 not all of the machine registers must be general registers. All 5874 the machine registers that can be used for storage of data are 5875 given hard register numbers, even those that can be used only in 5876 certain instructions or can hold only certain types of data. 5877 5878 A hard register may be accessed in various modes throughout one 5879 function, but each pseudo register is given a natural mode and is 5880 accessed only in that mode. When it is necessary to describe an 5881 access to a pseudo register using a nonnatural mode, a `subreg' 5882 expression is used. 5883 5884 A `reg' expression with a machine mode that specifies more than 5885 one word of data may actually stand for several consecutive 5886 registers. If in addition the register number specifies a 5887 hardware register, then it actually represents several consecutive 5888 hardware registers starting with the specified one. 5889 5890 Each pseudo register number used in a function's RTL code is 5891 represented by a unique `reg' expression. 5892 5893 Some pseudo register numbers, those within the range of 5894 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 5895 during the RTL generation phase and are eliminated before the 5896 optimization phases. These represent locations in the stack frame 5897 that cannot be determined until RTL generation for the function 5898 has been completed. The following virtual register numbers are 5899 defined: 5900 5901 `VIRTUAL_INCOMING_ARGS_REGNUM' 5902 This points to the first word of the incoming arguments 5903 passed on the stack. Normally these arguments are placed 5904 there by the caller, but the callee may have pushed some 5905 arguments that were previously passed in registers. 5906 5907 When RTL generation is complete, this virtual register is 5908 replaced by the sum of the register given by 5909 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 5910 5911 `VIRTUAL_STACK_VARS_REGNUM' 5912 If `FRAME_GROWS_DOWNWARD' is defined, this points to 5913 immediately above the first variable on the stack. 5914 Otherwise, it points to the first variable on the stack. 5915 5916 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 5917 register given by `FRAME_POINTER_REGNUM' and the value 5918 `STARTING_FRAME_OFFSET'. 5919 5920 `VIRTUAL_STACK_DYNAMIC_REGNUM' 5921 This points to the location of dynamically allocated memory 5922 on the stack immediately after the stack pointer has been 5923 adjusted by the amount of memory desired. 5924 5925 This virtual register is replaced by the sum of the register 5926 given by `STACK_POINTER_REGNUM' and the value 5927 `STACK_DYNAMIC_OFFSET'. 5928 5929 `VIRTUAL_OUTGOING_ARGS_REGNUM' 5930 This points to the location in the stack at which outgoing 5931 arguments should be written when the stack is pre-pushed 5932 (arguments pushed using push insns should always use 5933 `STACK_POINTER_REGNUM'). 5934 5935 This virtual register is replaced by the sum of the register 5936 given by `STACK_POINTER_REGNUM' and the value 5937 `STACK_POINTER_OFFSET'. 5938 5939`(subreg:M REG BYTENUM)' 5940 `subreg' expressions are used to refer to a register in a machine 5941 mode other than its natural one, or to refer to one register of a 5942 multi-part `reg' that actually refers to several registers. 5943 5944 Each pseudo-register has a natural mode. If it is necessary to 5945 operate on it in a different mode--for example, to perform a 5946 fullword move instruction on a pseudo-register that contains a 5947 single byte--the pseudo-register must be enclosed in a `subreg'. 5948 In such a case, BYTENUM is zero. 5949 5950 Usually M is at least as narrow as the mode of REG, in which case 5951 it is restricting consideration to only the bits of REG that are 5952 in M. 5953 5954 Sometimes M is wider than the mode of REG. These `subreg' 5955 expressions are often called "paradoxical". They are used in 5956 cases where we want to refer to an object in a wider mode but do 5957 not care what value the additional bits have. The reload pass 5958 ensures that paradoxical references are only made to hard 5959 registers. 5960 5961 The other use of `subreg' is to extract the individual registers of 5962 a multi-register value. Machine modes such as `DImode' and 5963 `TImode' can indicate values longer than a word, values which 5964 usually require two or more consecutive registers. To access one 5965 of the registers, use a `subreg' with mode `SImode' and a BYTENUM 5966 offset that says which register. 5967 5968 Storing in a non-paradoxical `subreg' has undefined results for 5969 bits belonging to the same word as the `subreg'. This laxity makes 5970 it easier to generate efficient code for such instructions. To 5971 represent an instruction that preserves all the bits outside of 5972 those in the `subreg', use `strict_low_part' around the `subreg'. 5973 5974 The compilation parameter `WORDS_BIG_ENDIAN', if set to 1, says 5975 that byte number zero is part of the most significant word; 5976 otherwise, it is part of the least significant word. 5977 5978 The compilation parameter `BYTES_BIG_ENDIAN', if set to 1, says 5979 that byte number zero is the most significant byte within a word; 5980 otherwise, it is the least significant byte within a word. 5981 5982 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with 5983 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 5984 floating point values as if they had the same endianness as 5985 integer values. This works because they handle them solely as a 5986 collection of integer values, with no particular numerical value. 5987 Only real.c and the runtime libraries care about 5988 `FLOAT_WORDS_BIG_ENDIAN'. 5989 5990 Between the combiner pass and the reload pass, it is possible to 5991 have a paradoxical `subreg' which contains a `mem' instead of a 5992 `reg' as its first operand. After the reload pass, it is also 5993 possible to have a non-paradoxical `subreg' which contains a 5994 `mem'; this usually occurs when the `mem' is a stack slot which 5995 replaced a pseudo register. 5996 5997 Note that it is not valid to access a `DFmode' value in `SFmode' 5998 using a `subreg'. On some machines the most significant part of a 5999 `DFmode' value does not have the same format as a single-precision 6000 floating value. 6001 6002 It is also not valid to access a single word of a multi-word value 6003 in a hard register when less registers can hold the value than 6004 would be expected from its size. For example, some 32-bit 6005 machines have floating-point registers that can hold an entire 6006 `DFmode' value. If register 10 were such a register `(subreg:SI 6007 (reg:DF 10) 1)' would be invalid because there is no way to 6008 convert that reference to a single machine register. The reload 6009 pass prevents `subreg' expressions such as these from being formed. 6010 6011 The first operand of a `subreg' expression is customarily accessed 6012 with the `SUBREG_REG' macro and the second operand is customarily 6013 accessed with the `SUBREG_BYTE' macro. 6014 6015`(scratch:M)' 6016 This represents a scratch register that will be required for the 6017 execution of a single instruction and not used subsequently. It is 6018 converted into a `reg' by either the local register allocator or 6019 the reload pass. 6020 6021 `scratch' is usually present inside a `clobber' operation (*note 6022 Side Effects::). 6023 6024`(cc0)' 6025 This refers to the machine's condition code register. It has no 6026 operands and may not have a machine mode. There are two ways to 6027 use it: 6028 6029 * To stand for a complete set of condition code flags. This is 6030 best on most machines, where each comparison sets the entire 6031 series of flags. 6032 6033 With this technique, `(cc0)' may be validly used in only two 6034 contexts: as the destination of an assignment (in test and 6035 compare instructions) and in comparison operators comparing 6036 against zero (`const_int' with value zero; that is to say, 6037 `const0_rtx'). 6038 6039 * To stand for a single flag that is the result of a single 6040 condition. This is useful on machines that have only a 6041 single flag bit, and in which comparison instructions must 6042 specify the condition to test. 6043 6044 With this technique, `(cc0)' may be validly used in only two 6045 contexts: as the destination of an assignment (in test and 6046 compare instructions) where the source is a comparison 6047 operator, and as the first operand of `if_then_else' (in a 6048 conditional branch). 6049 6050 There is only one expression object of code `cc0'; it is the value 6051 of the variable `cc0_rtx'. Any attempt to create an expression of 6052 code `cc0' will return `cc0_rtx'. 6053 6054 Instructions can set the condition code implicitly. On many 6055 machines, nearly all instructions set the condition code based on 6056 the value that they compute or store. It is not necessary to 6057 record these actions explicitly in the RTL because the machine 6058 description includes a prescription for recognizing the 6059 instructions that do so (by means of the macro 6060 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 6061 whose sole purpose is to set the condition code, and instructions 6062 that use the condition code, need mention `(cc0)'. 6063 6064 On some machines, the condition code register is given a register 6065 number and a `reg' is used instead of `(cc0)'. This is usually the 6066 preferable approach if only a small subset of instructions modify 6067 the condition code. Other machines store condition codes in 6068 general registers; in such cases a pseudo register should be used. 6069 6070 Some machines, such as the SPARC and RS/6000, have two sets of 6071 arithmetic instructions, one that sets and one that does not set 6072 the condition code. This is best handled by normally generating 6073 the instruction that does not set the condition code, and making a 6074 pattern that both performs the arithmetic and sets the condition 6075 code register (which would not be `(cc0)' in this case). For 6076 examples, search for `addcc' and `andcc' in `sparc.md'. 6077 6078`(pc)' 6079 This represents the machine's program counter. It has no operands 6080 and may not have a machine mode. `(pc)' may be validly used only 6081 in certain specific contexts in jump instructions. 6082 6083 There is only one expression object of code `pc'; it is the value 6084 of the variable `pc_rtx'. Any attempt to create an expression of 6085 code `pc' will return `pc_rtx'. 6086 6087 All instructions that do not jump alter the program counter 6088 implicitly by incrementing it, but there is no need to mention 6089 this in the RTL. 6090 6091`(mem:M ADDR ALIAS)' 6092 This RTX represents a reference to main memory at an address 6093 represented by the expression ADDR. M specifies how large a unit 6094 of memory is accessed. ALIAS specifies an alias set for the 6095 reference. In general two items are in different alias sets if 6096 they cannot reference the same memory address. 6097 6098 The construct `(mem:BLK (scratch))' is considered to alias all 6099 other memories. Thus it may be used as a memory barrier in 6100 epilogue stack deallocation patterns. 6101 6102`(addressof:M REG)' 6103 This RTX represents a request for the address of register REG. 6104 Its mode is always `Pmode'. If there are any `addressof' 6105 expressions left in the function after CSE, REG is forced into the 6106 stack and the `addressof' expression is replaced with a `plus' 6107 expression for the address of its stack slot. 6108 6109 6110File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 6111 61129.9 RTL Expressions for Arithmetic 6113================================== 6114 6115Unless otherwise specified, all the operands of arithmetic expressions 6116must be valid for mode M. An operand is valid for mode M if it has 6117mode M, or if it is a `const_int' or `const_double' and M is a mode of 6118class `MODE_INT'. 6119 6120 For commutative binary operations, constants should be placed in the 6121second operand. 6122 6123`(plus:M X Y)' 6124 Represents the sum of the values represented by X and Y carried 6125 out in machine mode M. 6126 6127`(lo_sum:M X Y)' 6128 Like `plus', except that it represents that sum of X and the 6129 low-order bits of Y. The number of low order bits is 6130 machine-dependent but is normally the number of bits in a `Pmode' 6131 item minus the number of bits set by the `high' code (*note 6132 Constants::). 6133 6134 M should be `Pmode'. 6135 6136`(minus:M X Y)' 6137 Like `plus' but represents subtraction. 6138 6139`(ss_plus:M X Y)' 6140 Like `plus', but using signed saturation in case of an overflow. 6141 6142`(us_plus:M X Y)' 6143 Like `plus', but using unsigned saturation in case of an overflow. 6144 6145`(ss_minus:M X Y)' 6146 Like `minus', but using signed saturation in case of an overflow. 6147 6148`(us_minus:M X Y)' 6149 Like `minus', but using unsigned saturation in case of an overflow. 6150 6151`(compare:M X Y)' 6152 Represents the result of subtracting Y from X for purposes of 6153 comparison. The result is computed without overflow, as if with 6154 infinite precision. 6155 6156 Of course, machines can't really subtract with infinite precision. 6157 However, they can pretend to do so when only the sign of the 6158 result will be used, which is the case when the result is stored 6159 in the condition code. And that is the _only_ way this kind of 6160 expression may validly be used: as a value to be stored in the 6161 condition codes, either `(cc0)' or a register. *Note 6162 Comparisons::. 6163 6164 The mode M is not related to the modes of X and Y, but instead is 6165 the mode of the condition code value. If `(cc0)' is used, it is 6166 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 6167 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or 6168 `CCmode', the operation returns sufficient information (in an 6169 unspecified format) so that any comparison operator can be applied 6170 to the result of the `COMPARE' operation. For other modes in 6171 class `MODE_CC', the operation only returns a subset of this 6172 information. 6173 6174 Normally, X and Y must have the same mode. Otherwise, `compare' 6175 is valid only if the mode of X is in class `MODE_INT' and Y is a 6176 `const_int' or `const_double' with mode `VOIDmode'. The mode of X 6177 determines what mode the comparison is to be done in; thus it must 6178 not be `VOIDmode'. 6179 6180 If one of the operands is a constant, it should be placed in the 6181 second operand and the comparison code adjusted as appropriate. 6182 6183 A `compare' specifying two `VOIDmode' constants is not valid since 6184 there is no way to know in what mode the comparison is to be 6185 performed; the comparison must either be folded during the 6186 compilation or the first operand must be loaded into a register 6187 while its mode is still known. 6188 6189`(neg:M X)' 6190 Represents the negation (subtraction from zero) of the value 6191 represented by X, carried out in mode M. 6192 6193`(mult:M X Y)' 6194 Represents the signed product of the values represented by X and Y 6195 carried out in machine mode M. 6196 6197 Some machines support a multiplication that generates a product 6198 wider than the operands. Write the pattern for this as 6199 6200 (mult:M (sign_extend:M X) (sign_extend:M Y)) 6201 6202 where M is wider than the modes of X and Y, which need not be the 6203 same. 6204 6205 For unsigned widening multiplication, use the same idiom, but with 6206 `zero_extend' instead of `sign_extend'. 6207 6208`(div:M X Y)' 6209 Represents the quotient in signed division of X by Y, carried out 6210 in machine mode M. If M is a floating point mode, it represents 6211 the exact quotient; otherwise, the integerized quotient. 6212 6213 Some machines have division instructions in which the operands and 6214 quotient widths are not all the same; you should represent such 6215 instructions using `truncate' and `sign_extend' as in, 6216 6217 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 6218 6219`(udiv:M X Y)' 6220 Like `div' but represents unsigned division. 6221 6222`(mod:M X Y)' 6223`(umod:M X Y)' 6224 Like `div' and `udiv' but represent the remainder instead of the 6225 quotient. 6226 6227`(smin:M X Y)' 6228`(smax:M X Y)' 6229 Represents the smaller (for `smin') or larger (for `smax') of X 6230 and Y, interpreted as signed integers in mode M. 6231 6232`(umin:M X Y)' 6233`(umax:M X Y)' 6234 Like `smin' and `smax', but the values are interpreted as unsigned 6235 integers. 6236 6237`(not:M X)' 6238 Represents the bitwise complement of the value represented by X, 6239 carried out in mode M, which must be a fixed-point machine mode. 6240 6241`(and:M X Y)' 6242 Represents the bitwise logical-and of the values represented by X 6243 and Y, carried out in machine mode M, which must be a fixed-point 6244 machine mode. 6245 6246`(ior:M X Y)' 6247 Represents the bitwise inclusive-or of the values represented by X 6248 and Y, carried out in machine mode M, which must be a fixed-point 6249 mode. 6250 6251`(xor:M X Y)' 6252 Represents the bitwise exclusive-or of the values represented by X 6253 and Y, carried out in machine mode M, which must be a fixed-point 6254 mode. 6255 6256`(ashift:M X C)' 6257 Represents the result of arithmetically shifting X left by C 6258 places. X have mode M, a fixed-point machine mode. C be a 6259 fixed-point mode or be a constant with mode `VOIDmode'; which mode 6260 is determined by the mode called for in the machine description 6261 entry for the left-shift instruction. For example, on the VAX, 6262 the mode of C is `QImode' regardless of M. 6263 6264`(lshiftrt:M X C)' 6265`(ashiftrt:M X C)' 6266 Like `ashift' but for right shift. Unlike the case for left shift, 6267 these two operations are distinct. 6268 6269`(rotate:M X C)' 6270`(rotatert:M X C)' 6271 Similar but represent left and right rotate. If C is a constant, 6272 use `rotate'. 6273 6274`(abs:M X)' 6275 Represents the absolute value of X, computed in mode M. 6276 6277`(sqrt:M X)' 6278 Represents the square root of X, computed in mode M. Most often M 6279 will be a floating point mode. 6280 6281`(ffs:M X)' 6282 Represents one plus the index of the least significant 1-bit in X, 6283 represented as an integer of mode M. (The value is zero if X is 6284 zero.) The mode of X need not be M; depending on the target 6285 machine, various mode combinations may be valid. 6286 6287`(clz:M X)' 6288 Represents the number of leading 0-bits in X, represented as an 6289 integer of mode M, starting at the most significant bit position. 6290 If X is zero, the value is determined by 6291 `CLZ_DEFINED_VALUE_AT_ZERO'. Note that this is one of the few 6292 expressions that is not invariant under widening. The mode of X 6293 will usually be an integer mode. 6294 6295`(ctz:M X)' 6296 Represents the number of trailing 0-bits in X, represented as an 6297 integer of mode M, starting at the least significant bit position. 6298 If X is zero, the value is determined by 6299 `CTZ_DEFINED_VALUE_AT_ZERO'. Except for this case, `ctz(x)' is 6300 equivalent to `ffs(X) - 1'. The mode of X will usually be an 6301 integer mode. 6302 6303`(popcount:M X)' 6304 Represents the number of 1-bits in X, represented as an integer of 6305 mode M. The mode of X will usually be an integer mode. 6306 6307`(parity:M X)' 6308 Represents the number of 1-bits modulo 2 in X, represented as an 6309 integer of mode M. The mode of X will usually be an integer mode. 6310 6311 6312File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 6313 63149.10 Comparison Operations 6315========================== 6316 6317Comparison operators test a relation on two operands and are considered 6318to represent a machine-dependent nonzero value described by, but not 6319necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation 6320holds, or zero if it does not, for comparison operators whose results 6321have a `MODE_INT' mode, and `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if 6322the relation holds, or zero if it does not, for comparison operators 6323that return floating-point values. The mode of the comparison 6324operation is independent of the mode of the data being compared. If 6325the comparison operation is being tested (e.g., the first operand of an 6326`if_then_else'), the mode must be `VOIDmode'. 6327 6328 There are two ways that comparison operations may be used. The 6329comparison operators may be used to compare the condition codes `(cc0)' 6330against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 6331actually refers to the result of the preceding instruction in which the 6332condition codes were set. The instruction setting the condition code 6333must be adjacent to the instruction using the condition code; only 6334`note' insns may separate them. 6335 6336 Alternatively, a comparison operation may directly compare two data 6337objects. The mode of the comparison is determined by the operands; they 6338must both be valid for a common machine mode. A comparison with both 6339operands constant would be invalid as the machine mode could not be 6340deduced from it, but such a comparison should never exist in RTL due to 6341constant folding. 6342 6343 In the example above, if `(cc0)' were last set to `(compare X Y)', 6344the comparison operation is identical to `(eq X Y)'. Usually only one 6345style of comparisons is supported on a particular machine, but the 6346combine pass will try to merge the operations to produce the `eq' shown 6347in case it exists in the context of the particular insn involved. 6348 6349 Inequality comparisons come in two flavors, signed and unsigned. 6350Thus, there are distinct expression codes `gt' and `gtu' for signed and 6351unsigned greater-than. These can produce different results for the same 6352pair of integer values: for example, 1 is signed greater-than -1 but not 6353unsigned greater-than, because -1 when regarded as unsigned is actually 6354`0xffffffff' which is greater than 1. 6355 6356 The signed comparisons are also used for floating point values. 6357Floating point comparisons are distinguished by the machine modes of 6358the operands. 6359 6360`(eq:M X Y)' 6361 `STORE_FLAG_VALUE' if the values represented by X and Y are equal, 6362 otherwise 0. 6363 6364`(ne:M X Y)' 6365 `STORE_FLAG_VALUE' if the values represented by X and Y are not 6366 equal, otherwise 0. 6367 6368`(gt:M X Y)' 6369 `STORE_FLAG_VALUE' if the X is greater than Y. If they are 6370 fixed-point, the comparison is done in a signed sense. 6371 6372`(gtu:M X Y)' 6373 Like `gt' but does unsigned comparison, on fixed-point numbers 6374 only. 6375 6376`(lt:M X Y)' 6377`(ltu:M X Y)' 6378 Like `gt' and `gtu' but test for "less than". 6379 6380`(ge:M X Y)' 6381`(geu:M X Y)' 6382 Like `gt' and `gtu' but test for "greater than or equal". 6383 6384`(le:M X Y)' 6385`(leu:M X Y)' 6386 Like `gt' and `gtu' but test for "less than or equal". 6387 6388`(if_then_else COND THEN ELSE)' 6389 This is not a comparison operation but is listed here because it is 6390 always used in conjunction with a comparison operation. To be 6391 precise, COND is a comparison expression. This expression 6392 represents a choice, according to COND, between the value 6393 represented by THEN and the one represented by ELSE. 6394 6395 On most machines, `if_then_else' expressions are valid only to 6396 express conditional jumps. 6397 6398`(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 6399 Similar to `if_then_else', but more general. Each of TEST1, 6400 TEST2, ... is performed in turn. The result of this expression is 6401 the VALUE corresponding to the first nonzero test, or DEFAULT if 6402 none of the tests are nonzero expressions. 6403 6404 This is currently not valid for instruction patterns and is 6405 supported only for insn attributes. *Note Insn Attributes::. 6406 6407 6408File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 6409 64109.11 Bit-Fields 6411=============== 6412 6413Special expression codes exist to represent bit-field instructions. 6414These types of expressions are lvalues in RTL; they may appear on the 6415left side of an assignment, indicating insertion of a value into the 6416specified bit-field. 6417 6418`(sign_extract:M LOC SIZE POS)' 6419 This represents a reference to a sign-extended bit-field contained 6420 or starting in LOC (a memory or register reference). The bit-field 6421 is SIZE bits wide and starts at bit POS. The compilation option 6422 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 6423 from. 6424 6425 If LOC is in memory, its mode must be a single-byte integer mode. 6426 If LOC is in a register, the mode to use is specified by the 6427 operand of the `insv' or `extv' pattern (*note Standard Names::) 6428 and is usually a full-word integer mode, which is the default if 6429 none is specified. 6430 6431 The mode of POS is machine-specific and is also specified in the 6432 `insv' or `extv' pattern. 6433 6434 The mode M is the same as the mode that would be used for LOC if 6435 it were a register. 6436 6437`(zero_extract:M LOC SIZE POS)' 6438 Like `sign_extract' but refers to an unsigned or zero-extended 6439 bit-field. The same sequence of bits are extracted, but they are 6440 filled to an entire word with zeros instead of by sign-extension. 6441 6442 6443File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 6444 64459.12 Vector Operations 6446====================== 6447 6448All normal RTL expressions can be used with vector modes; they are 6449interpreted as operating on each part of the vector independently. 6450Additionally, there are a few new expressions to describe specific 6451vector operations. 6452 6453`(vec_merge:M VEC1 VEC2 ITEMS)' 6454 This describes a merge operation between two vectors. The result 6455 is a vector of mode M; its elements are selected from either VEC1 6456 or VEC2. Which elements are selected is described by ITEMS, which 6457 is a bit mask represented by a `const_int'; a zero bit indicates 6458 the corresponding element in the result vector is taken from VEC2 6459 while a set bit indicates it is taken from VEC1. 6460 6461`(vec_select:M VEC1 SELECTION)' 6462 This describes an operation that selects parts of a vector. VEC1 6463 is the source vector, SELECTION is a `parallel' that contains a 6464 `const_int' for each of the subparts of the result vector, giving 6465 the number of the source subpart that should be stored into it. 6466 6467`(vec_concat:M VEC1 VEC2)' 6468 Describes a vector concat operation. The result is a 6469 concatenation of the vectors VEC1 and VEC2; its length is the sum 6470 of the lengths of the two inputs. 6471 6472`(vec_duplicate:M VEC)' 6473 This operation converts a small vector into a larger one by 6474 duplicating the input values. The output vector mode must have 6475 the same submodes as the input vector mode, and the number of 6476 output parts must be an integer multiple of the number of input 6477 parts. 6478 6479 6480 6481File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 6482 64839.13 Conversions 6484================ 6485 6486All conversions between machine modes must be represented by explicit 6487conversion operations. For example, an expression which is the sum of 6488a byte and a full word cannot be written as `(plus:SI (reg:QI 34) 6489(reg:SI 80))' because the `plus' operation requires two operands of the 6490same machine mode. Therefore, the byte-sized operand is enclosed in a 6491conversion operation, as in 6492 6493 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 6494 6495 The conversion operation is not a mere placeholder, because there 6496may be more than one way of converting from a given starting mode to 6497the desired final mode. The conversion operation code says how to do 6498it. 6499 6500 For all conversion operations, X must not be `VOIDmode' because the 6501mode in which to do the conversion would not be known. The conversion 6502must either be done at compile-time or X must be placed into a register. 6503 6504`(sign_extend:M X)' 6505 Represents the result of sign-extending the value X to machine 6506 mode M. M must be a fixed-point mode and X a fixed-point value of 6507 a mode narrower than M. 6508 6509`(zero_extend:M X)' 6510 Represents the result of zero-extending the value X to machine 6511 mode M. M must be a fixed-point mode and X a fixed-point value of 6512 a mode narrower than M. 6513 6514`(float_extend:M X)' 6515 Represents the result of extending the value X to machine mode M. 6516 M must be a floating point mode and X a floating point value of a 6517 mode narrower than M. 6518 6519`(truncate:M X)' 6520 Represents the result of truncating the value X to machine mode M. 6521 M must be a fixed-point mode and X a fixed-point value of a mode 6522 wider than M. 6523 6524`(ss_truncate:M X)' 6525 Represents the result of truncating the value X to machine mode M, 6526 using signed saturation in the case of overflow. Both M and the 6527 mode of X must be fixed-point modes. 6528 6529`(us_truncate:M X)' 6530 Represents the result of truncating the value X to machine mode M, 6531 using unsigned saturation in the case of overflow. Both M and the 6532 mode of X must be fixed-point modes. 6533 6534`(float_truncate:M X)' 6535 Represents the result of truncating the value X to machine mode M. 6536 M must be a floating point mode and X a floating point value of a 6537 mode wider than M. 6538 6539`(float:M X)' 6540 Represents the result of converting fixed point value X, regarded 6541 as signed, to floating point mode M. 6542 6543`(unsigned_float:M X)' 6544 Represents the result of converting fixed point value X, regarded 6545 as unsigned, to floating point mode M. 6546 6547`(fix:M X)' 6548 When M is a fixed point mode, represents the result of converting 6549 floating point value X to mode M, regarded as signed. How 6550 rounding is done is not specified, so this operation may be used 6551 validly in compiling C code only for integer-valued operands. 6552 6553`(unsigned_fix:M X)' 6554 Represents the result of converting floating point value X to 6555 fixed point mode M, regarded as unsigned. How rounding is done is 6556 not specified. 6557 6558`(fix:M X)' 6559 When M is a floating point mode, represents the result of 6560 converting floating point value X (valid for mode M) to an 6561 integer, still represented in floating point mode M, by rounding 6562 towards zero. 6563 6564 6565File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 6566 65679.14 Declarations 6568================= 6569 6570Declaration expression codes do not represent arithmetic operations but 6571rather state assertions about their operands. 6572 6573`(strict_low_part (subreg:M (reg:N R) 0))' 6574 This expression code is used in only one context: as the 6575 destination operand of a `set' expression. In addition, the 6576 operand of this expression must be a non-paradoxical `subreg' 6577 expression. 6578 6579 The presence of `strict_low_part' says that the part of the 6580 register which is meaningful in mode N, but is not part of mode M, 6581 is not to be altered. Normally, an assignment to such a subreg is 6582 allowed to have undefined effects on the rest of the register when 6583 M is less than a word. 6584 6585 6586File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 6587 65889.15 Side Effect Expressions 6589============================ 6590 6591The expression codes described so far represent values, not actions. 6592But machine instructions never produce values; they are meaningful only 6593for their side effects on the state of the machine. Special expression 6594codes are used to represent side effects. 6595 6596 The body of an instruction is always one of these side effect codes; 6597the codes described above, which represent values, appear only as the 6598operands of these. 6599 6600`(set LVAL X)' 6601 Represents the action of storing the value of X into the place 6602 represented by LVAL. LVAL must be an expression representing a 6603 place that can be stored in: `reg' (or `subreg', `strict_low_part' 6604 or `zero_extract'), `mem', `pc', `parallel', or `cc0'. 6605 6606 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then 6607 X must be valid for that mode. 6608 6609 If LVAL is a `reg' whose machine mode is less than the full width 6610 of the register, then it means that the part of the register 6611 specified by the machine mode is given the specified value and the 6612 rest of the register receives an undefined value. Likewise, if 6613 LVAL is a `subreg' whose machine mode is narrower than the mode of 6614 the register, the rest of the register can be changed in an 6615 undefined way. 6616 6617 If LVAL is a `strict_low_part' or `zero_extract' of a `subreg', 6618 then the part of the register specified by the machine mode of the 6619 `subreg' is given the value X and the rest of the register is not 6620 changed. 6621 6622 If LVAL is `(cc0)', it has no machine mode, and X may be either a 6623 `compare' expression or a value that may have any mode. The 6624 latter case represents a "test" instruction. The expression `(set 6625 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) 6626 (const_int 0)))'. Use the former expression to save space during 6627 the compilation. 6628 6629 If LVAL is a `parallel', it is used to represent the case of a 6630 function returning a structure in multiple registers. Each element 6631 of the `parallel' is an `expr_list' whose first operand is a `reg' 6632 and whose second operand is a `const_int' representing the offset 6633 (in bytes) into the structure at which the data in that register 6634 corresponds. The first element may be null to indicate that the 6635 structure is also passed partly in memory. 6636 6637 If LVAL is `(pc)', we have a jump instruction, and the 6638 possibilities for X are very limited. It may be a `label_ref' 6639 expression (unconditional jump). It may be an `if_then_else' 6640 (conditional jump), in which case either the second or the third 6641 operand must be `(pc)' (for the case which does not jump) and the 6642 other of the two must be a `label_ref' (for the case which does 6643 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may 6644 be a `reg' or a `mem'; these unusual patterns are used to 6645 represent jumps through branch tables. 6646 6647 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not 6648 be `VOIDmode' and the mode of X must be valid for the mode of LVAL. 6649 6650 LVAL is customarily accessed with the `SET_DEST' macro and X with 6651 the `SET_SRC' macro. 6652 6653`(return)' 6654 As the sole expression in a pattern, represents a return from the 6655 current function, on machines where this can be done with one 6656 instruction, such as VAXen. On machines where a multi-instruction 6657 "epilogue" must be executed in order to return from the function, 6658 returning is done by jumping to a label which precedes the 6659 epilogue, and the `return' expression code is never used. 6660 6661 Inside an `if_then_else' expression, represents the value to be 6662 placed in `pc' to return to the caller. 6663 6664 Note that an insn pattern of `(return)' is logically equivalent to 6665 `(set (pc) (return))', but the latter form is never used. 6666 6667`(call FUNCTION NARGS)' 6668 Represents a function call. FUNCTION is a `mem' expression whose 6669 address is the address of the function to be called. NARGS is an 6670 expression which can be used for two purposes: on some machines it 6671 represents the number of bytes of stack argument; on others, it 6672 represents the number of argument registers. 6673 6674 Each machine has a standard machine mode which FUNCTION must have. 6675 The machine description defines macro `FUNCTION_MODE' to expand 6676 into the requisite mode name. The purpose of this mode is to 6677 specify what kind of addressing is allowed, on machines where the 6678 allowed kinds of addressing depend on the machine mode being 6679 addressed. 6680 6681`(clobber X)' 6682 Represents the storing or possible storing of an unpredictable, 6683 undescribed value into X, which must be a `reg', `scratch', 6684 `parallel' or `mem' expression. 6685 6686 One place this is used is in string instructions that store 6687 standard values into particular hard registers. It may not be 6688 worth the trouble to describe the values that are stored, but it 6689 is essential to inform the compiler that the registers will be 6690 altered, lest it attempt to keep data in them across the string 6691 instruction. 6692 6693 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it 6694 means that all memory locations must be presumed clobbered. If X 6695 is a `parallel', it has the same meaning as a `parallel' in a 6696 `set' expression. 6697 6698 Note that the machine description classifies certain hard 6699 registers as "call-clobbered". All function call instructions are 6700 assumed by default to clobber these registers, so there is no need 6701 to use `clobber' expressions to indicate this fact. Also, each 6702 function call is assumed to have the potential to alter any memory 6703 location, unless the function is declared `const'. 6704 6705 If the last group of expressions in a `parallel' are each a 6706 `clobber' expression whose arguments are `reg' or `match_scratch' 6707 (*note RTL Template::) expressions, the combiner phase can add the 6708 appropriate `clobber' expressions to an insn it has constructed 6709 when doing so will cause a pattern to be matched. 6710 6711 This feature can be used, for example, on a machine that whose 6712 multiply and add instructions don't use an MQ register but which 6713 has an add-accumulate instruction that does clobber the MQ 6714 register. Similarly, a combined instruction might require a 6715 temporary register while the constituent instructions might not. 6716 6717 When a `clobber' expression for a register appears inside a 6718 `parallel' with other side effects, the register allocator 6719 guarantees that the register is unoccupied both before and after 6720 that insn. However, the reload phase may allocate a register used 6721 for one of the inputs unless the `&' constraint is specified for 6722 the selected alternative (*note Modifiers::). You can clobber 6723 either a specific hard register, a pseudo register, or a `scratch' 6724 expression; in the latter two cases, GCC will allocate a hard 6725 register that is available there for use as a temporary. 6726 6727 For instructions that require a temporary register, you should use 6728 `scratch' instead of a pseudo-register because this will allow the 6729 combiner phase to add the `clobber' when required. You do this by 6730 coding (`clobber' (`match_scratch' ...)). If you do clobber a 6731 pseudo register, use one which appears nowhere else--generate a 6732 new one each time. Otherwise, you may confuse CSE. 6733 6734 There is one other known use for clobbering a pseudo register in a 6735 `parallel': when one of the input operands of the insn is also 6736 clobbered by the insn. In this case, using the same pseudo 6737 register in the clobber and elsewhere in the insn produces the 6738 expected results. 6739 6740`(use X)' 6741 Represents the use of the value of X. It indicates that the value 6742 in X at this point in the program is needed, even though it may 6743 not be apparent why this is so. Therefore, the compiler will not 6744 attempt to delete previous instructions whose only effect is to 6745 store a value in X. X must be a `reg' expression. 6746 6747 In some situations, it may be tempting to add a `use' of a 6748 register in a `parallel' to describe a situation where the value 6749 of a special register will modify the behavior of the instruction. 6750 An hypothetical example might be a pattern for an addition that can 6751 either wrap around or use saturating addition depending on the 6752 value of a special control register: 6753 6754 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 6755 (reg:SI 4)] 0)) 6756 (use (reg:SI 1))]) 6757 6758 This will not work, several of the optimizers only look at 6759 expressions locally; it is very likely that if you have multiple 6760 insns with identical inputs to the `unspec', they will be 6761 optimized away even if register 1 changes in between. 6762 6763 This means that `use' can _only_ be used to describe that the 6764 register is live. You should think twice before adding `use' 6765 statements, more often you will want to use `unspec' instead. The 6766 `use' RTX is most commonly useful to describe that a fixed 6767 register is implicitly used in an insn. It is also safe to use in 6768 patterns where the compiler knows for other reasons that the result 6769 of the whole pattern is variable, such as `movstrM' or `call' 6770 patterns. 6771 6772 During the reload phase, an insn that has a `use' as pattern can 6773 carry a reg_equal note. These `use' insns will be deleted before 6774 the reload phase exits. 6775 6776 During the delayed branch scheduling phase, X may be an insn. 6777 This indicates that X previously was located at this place in the 6778 code and its data dependencies need to be taken into account. 6779 These `use' insns will be deleted before the delayed branch 6780 scheduling phase exits. 6781 6782`(parallel [X0 X1 ...])' 6783 Represents several side effects performed in parallel. The square 6784 brackets stand for a vector; the operand of `parallel' is a vector 6785 of expressions. X0, X1 and so on are individual side effect 6786 expressions--expressions of code `set', `call', `return', 6787 `clobber' or `use'. 6788 6789 "In parallel" means that first all the values used in the 6790 individual side-effects are computed, and second all the actual 6791 side-effects are performed. For example, 6792 6793 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 6794 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 6795 6796 says unambiguously that the values of hard register 1 and the 6797 memory location addressed by it are interchanged. In both places 6798 where `(reg:SI 1)' appears as a memory address it refers to the 6799 value in register 1 _before_ the execution of the insn. 6800 6801 It follows that it is _incorrect_ to use `parallel' and expect the 6802 result of one `set' to be available for the next one. For 6803 example, people sometimes attempt to represent a jump-if-zero 6804 instruction this way: 6805 6806 (parallel [(set (cc0) (reg:SI 34)) 6807 (set (pc) (if_then_else 6808 (eq (cc0) (const_int 0)) 6809 (label_ref ...) 6810 (pc)))]) 6811 6812 But this is incorrect, because it says that the jump condition 6813 depends on the condition code value _before_ this instruction, not 6814 on the new value that is set by this instruction. 6815 6816 Peephole optimization, which takes place together with final 6817 assembly code output, can produce insns whose patterns consist of 6818 a `parallel' whose elements are the operands needed to output the 6819 resulting assembler code--often `reg', `mem' or constant 6820 expressions. This would not be well-formed RTL at any other stage 6821 in compilation, but it is ok then because no further optimization 6822 remains to be done. However, the definition of the macro 6823 `NOTICE_UPDATE_CC', if any, must deal with such insns if you 6824 define any peephole optimizations. 6825 6826`(cond_exec [COND EXPR])' 6827 Represents a conditionally executed expression. The EXPR is 6828 executed only if the COND is nonzero. The COND expression must 6829 not have side-effects, but the EXPR may very well have 6830 side-effects. 6831 6832`(sequence [INSNS ...])' 6833 Represents a sequence of insns. Each of the INSNS that appears in 6834 the vector is suitable for appearing in the chain of insns, so it 6835 must be an `insn', `jump_insn', `call_insn', `code_label', 6836 `barrier' or `note'. 6837 6838 A `sequence' RTX is never placed in an actual insn during RTL 6839 generation. It represents the sequence of insns that result from a 6840 `define_expand' _before_ those insns are passed to `emit_insn' to 6841 insert them in the chain of insns. When actually inserted, the 6842 individual sub-insns are separated out and the `sequence' is 6843 forgotten. 6844 6845 After delay-slot scheduling is completed, an insn and all the 6846 insns that reside in its delay slots are grouped together into a 6847 `sequence'. The insn requiring the delay slot is the first insn 6848 in the vector; subsequent insns are to be placed in the delay slot. 6849 6850 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 6851 indicate that a branch insn should be used that will conditionally 6852 annul the effect of the insns in the delay slots. In such a case, 6853 `INSN_FROM_TARGET_P' indicates that the insn is from the target of 6854 the branch and should be executed only if the branch is taken; 6855 otherwise the insn should be executed only if the branch is not 6856 taken. *Note Delay Slots::. 6857 6858 These expression codes appear in place of a side effect, as the body 6859of an insn, though strictly speaking they do not always describe side 6860effects as such: 6861 6862`(asm_input S)' 6863 Represents literal assembler code as described by the string S. 6864 6865`(unspec [OPERANDS ...] INDEX)' 6866`(unspec_volatile [OPERANDS ...] INDEX)' 6867 Represents a machine-specific operation on OPERANDS. INDEX 6868 selects between multiple machine-specific operations. 6869 `unspec_volatile' is used for volatile operations and operations 6870 that may trap; `unspec' is used for other operations. 6871 6872 These codes may appear inside a `pattern' of an insn, inside a 6873 `parallel', or inside an expression. 6874 6875`(addr_vec:M [LR0 LR1 ...])' 6876 Represents a table of jump addresses. The vector elements LR0, 6877 etc., are `label_ref' expressions. The mode M specifies how much 6878 space is given to each address; normally M would be `Pmode'. 6879 6880`(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 6881 Represents a table of jump addresses expressed as offsets from 6882 BASE. The vector elements LR0, etc., are `label_ref' expressions 6883 and so is BASE. The mode M specifies how much space is given to 6884 each address-difference. MIN and MAX are set up by branch 6885 shortening and hold a label with a minimum and a maximum address, 6886 respectively. FLAGS indicates the relative position of BASE, MIN 6887 and MAX to the containing insn and of MIN and MAX to BASE. See 6888 rtl.def for details. 6889 6890`(prefetch:M ADDR RW LOCALITY)' 6891 Represents prefetch of memory at address ADDR. Operand RW is 1 if 6892 the prefetch is for data to be written, 0 otherwise; targets that 6893 do not support write prefetches should treat this as a normal 6894 prefetch. Operand LOCALITY specifies the amount of temporal 6895 locality; 0 if there is none or 1, 2, or 3 for increasing levels 6896 of temporal locality; targets that do not support locality hints 6897 should ignore this. 6898 6899 This insn is used to minimize cache-miss latency by moving data 6900 into a cache before it is accessed. It should use only 6901 non-faulting data prefetch instructions. 6902 6903 6904File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 6905 69069.16 Embedded Side-Effects on Addresses 6907======================================= 6908 6909Six special side-effect expression codes appear as memory addresses. 6910 6911`(pre_dec:M X)' 6912 Represents the side effect of decrementing X by a standard amount 6913 and represents also the value that X has after being decremented. 6914 X must be a `reg' or `mem', but most machines allow only a `reg'. 6915 M must be the machine mode for pointers on the machine in use. 6916 The amount X is decremented by is the length in bytes of the 6917 machine mode of the containing memory reference of which this 6918 expression serves as the address. Here is an example of its use: 6919 6920 (mem:DF (pre_dec:SI (reg:SI 39))) 6921 6922 This says to decrement pseudo register 39 by the length of a 6923 `DFmode' value and use the result to address a `DFmode' value. 6924 6925`(pre_inc:M X)' 6926 Similar, but specifies incrementing X instead of decrementing it. 6927 6928`(post_dec:M X)' 6929 Represents the same side effect as `pre_dec' but a different 6930 value. The value represented here is the value X has before being 6931 decremented. 6932 6933`(post_inc:M X)' 6934 Similar, but specifies incrementing X instead of decrementing it. 6935 6936`(post_modify:M X Y)' 6937 Represents the side effect of setting X to Y and represents X 6938 before X is modified. X must be a `reg' or `mem', but most 6939 machines allow only a `reg'. M must be the machine mode for 6940 pointers on the machine in use. 6941 6942 The expression Y must be one of three forms: 6943 `(plus:M X Z)', `(minus:M X Z)', or `(plus:M X I)', 6944 where Z is an index register and I is a constant. 6945 6946 Here is an example of its use: 6947 6948 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 6949 (reg:SI 48)))) 6950 6951 This says to modify pseudo register 42 by adding the contents of 6952 pseudo register 48 to it, after the use of what ever 42 points to. 6953 6954`(pre_modify:M X EXPR)' 6955 Similar except side effects happen before the use. 6956 6957 These embedded side effect expressions must be used with care. 6958Instruction patterns may not use them. Until the `flow' pass of the 6959compiler, they may occur only to represent pushes onto the stack. The 6960`flow' pass finds cases where registers are incremented or decremented 6961in one instruction and used as an address shortly before or after; 6962these cases are then transformed to use pre- or post-increment or 6963-decrement. 6964 6965 If a register used as the operand of these expressions is used in 6966another address in an insn, the original value of the register is used. 6967Uses of the register outside of an address are not permitted within the 6968same insn as a use in an embedded side effect expression because such 6969insns behave differently on different machines and hence must be treated 6970as ambiguous and disallowed. 6971 6972 An instruction that can be represented with an embedded side effect 6973could also be represented using `parallel' containing an additional 6974`set' to describe how the address register is altered. This is not 6975done because machines that allow these operations at all typically 6976allow them wherever a memory address is called for. Describing them as 6977additional parallel stores would require doubling the number of entries 6978in the machine description. 6979 6980 6981File: gccint.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL 6982 69839.17 Assembler Instructions as Expressions 6984========================================== 6985 6986The RTX code `asm_operands' represents a value produced by a 6987user-specified assembler instruction. It is used to represent an `asm' 6988statement with arguments. An `asm' statement with a single output 6989operand, like this: 6990 6991 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 6992 6993is represented using a single `asm_operands' RTX which represents the 6994value that is stored in `outputvar': 6995 6996 (set RTX-FOR-OUTPUTVAR 6997 (asm_operands "foo %1,%2,%0" "a" 0 6998 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 6999 [(asm_input:M1 "g") 7000 (asm_input:M2 "di")])) 7001 7002Here the operands of the `asm_operands' RTX are the assembler template 7003string, the output-operand's constraint, the index-number of the output 7004operand among the output operands specified, a vector of input operand 7005RTX's, and a vector of input-operand modes and constraints. The mode 7006M1 is the mode of the sum `x+y'; M2 is that of `*z'. 7007 7008 When an `asm' statement has multiple output values, its insn has 7009several such `set' RTX's inside of a `parallel'. Each `set' contains a 7010`asm_operands'; all of these share the same assembler template and 7011vectors, but each contains the constraint for the respective output 7012operand. They are also distinguished by the output-operand index 7013number, which is 0, 1, ... for successive output operands. 7014 7015 7016File: gccint.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL 7017 70189.18 Insns 7019========== 7020 7021The RTL representation of the code for a function is a doubly-linked 7022chain of objects called "insns". Insns are expressions with special 7023codes that are used for no other purpose. Some insns are actual 7024instructions; others represent dispatch tables for `switch' statements; 7025others represent labels to jump to or various sorts of declarative 7026information. 7027 7028 In addition to its own specific data, each insn must have a unique 7029id-number that distinguishes it from all other insns in the current 7030function (after delayed branch scheduling, copies of an insn with the 7031same id-number may be present in multiple places in a function, but 7032these copies will always be identical and will only appear inside a 7033`sequence'), and chain pointers to the preceding and following insns. 7034These three fields occupy the same position in every insn, independent 7035of the expression code of the insn. They could be accessed with `XEXP' 7036and `XINT', but instead three special macros are always used: 7037 7038`INSN_UID (I)' 7039 Accesses the unique id of insn I. 7040 7041`PREV_INSN (I)' 7042 Accesses the chain pointer to the insn preceding I. If I is the 7043 first insn, this is a null pointer. 7044 7045`NEXT_INSN (I)' 7046 Accesses the chain pointer to the insn following I. If I is the 7047 last insn, this is a null pointer. 7048 7049 The first insn in the chain is obtained by calling `get_insns'; the 7050last insn is the result of calling `get_last_insn'. Within the chain 7051delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must 7052always correspond: if INSN is not the first insn, 7053 7054 NEXT_INSN (PREV_INSN (INSN)) == INSN 7055 7056is always true and if INSN is not the last insn, 7057 7058 PREV_INSN (NEXT_INSN (INSN)) == INSN 7059 7060is always true. 7061 7062 After delay slot scheduling, some of the insns in the chain might be 7063`sequence' expressions, which contain a vector of insns. The value of 7064`NEXT_INSN' in all but the last of these insns is the next insn in the 7065vector; the value of `NEXT_INSN' of the last insn in the vector is the 7066same as the value of `NEXT_INSN' for the `sequence' in which it is 7067contained. Similar rules apply for `PREV_INSN'. 7068 7069 This means that the above invariants are not necessarily true for 7070insns inside `sequence' expressions. Specifically, if INSN is the 7071first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn 7072containing the `sequence' expression, as is the value of `PREV_INSN 7073(NEXT_INSN (INSN))' if INSN is the last insn in the `sequence' 7074expression. You can use these expressions to find the containing 7075`sequence' expression. 7076 7077 Every insn has one of the following six expression codes: 7078 7079`insn' 7080 The expression code `insn' is used for instructions that do not 7081 jump and do not do function calls. `sequence' expressions are 7082 always contained in insns with code `insn' even if one of those 7083 insns should jump or do function calls. 7084 7085 Insns with code `insn' have four additional fields beyond the three 7086 mandatory ones listed above. These four are described in a table 7087 below. 7088 7089`jump_insn' 7090 The expression code `jump_insn' is used for instructions that may 7091 jump (or, more generally, may contain `label_ref' expressions). If 7092 there is an instruction to return from the current function, it is 7093 recorded as a `jump_insn'. 7094 7095 `jump_insn' insns have the same extra fields as `insn' insns, 7096 accessed in the same way and in addition contain a field 7097 `JUMP_LABEL' which is defined once jump optimization has completed. 7098 7099 For simple conditional and unconditional jumps, this field contains 7100 the `code_label' to which this insn will (possibly conditionally) 7101 branch. In a more complex jump, `JUMP_LABEL' records one of the 7102 labels that the insn refers to; the only way to find the others is 7103 to scan the entire body of the insn. In an `addr_vec', 7104 `JUMP_LABEL' is `NULL_RTX'. 7105 7106 Return insns count as jumps, but since they do not refer to any 7107 labels, their `JUMP_LABEL' is `NULL_RTX'. 7108 7109`call_insn' 7110 The expression code `call_insn' is used for instructions that may 7111 do function calls. It is important to distinguish these 7112 instructions because they imply that certain registers and memory 7113 locations may be altered unpredictably. 7114 7115 `call_insn' insns have the same extra fields as `insn' insns, 7116 accessed in the same way and in addition contain a field 7117 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 7118 `expr_list' expressions) containing `use' and `clobber' 7119 expressions that denote hard registers and `MEM's used or 7120 clobbered by the called function. 7121 7122 A `MEM' generally points to a stack slots in which arguments passed 7123 to the libcall by reference (*note FUNCTION_ARG_PASS_BY_REFERENCE: 7124 Register Arguments.) are stored. If the argument is caller-copied 7125 (*note FUNCTION_ARG_CALLEE_COPIES: Register Arguments.), the stack 7126 slot will be mentioned in `CLOBBER' and `USE' entries; if it's 7127 callee-copied, only a `USE' will appear, and the `MEM' may point 7128 to addresses that are not stack slots. These `MEM's are used only 7129 in libcalls, because, unlike regular function calls, `CONST_CALL's 7130 (which libcalls generally are, *note CONST_CALL_P: Flags.) aren't 7131 assumed to read and write all memory, so flow would consider the 7132 stores dead and remove them. Note that, since a libcall must 7133 never return values in memory (*note RETURN_IN_MEMORY: Aggregate 7134 Return.), there will never be a `CLOBBER' for a memory address 7135 holding a return value. 7136 7137 `CLOBBER'ed registers in this list augment registers specified in 7138 `CALL_USED_REGISTERS' (*note Register Basics::). 7139 7140`code_label' 7141 A `code_label' insn represents a label that a jump insn can jump 7142 to. It contains two special fields of data in addition to the 7143 three standard ones. `CODE_LABEL_NUMBER' is used to hold the 7144 "label number", a number that identifies this label uniquely among 7145 all the labels in the compilation (not just in the current 7146 function). Ultimately, the label is represented in the assembler 7147 output as an assembler label, usually of the form `LN' where N is 7148 the label number. 7149 7150 When a `code_label' appears in an RTL expression, it normally 7151 appears within a `label_ref' which represents the address of the 7152 label, as a number. 7153 7154 Besides as a `code_label', a label can also be represented as a 7155 `note' of type `NOTE_INSN_DELETED_LABEL'. 7156 7157 The field `LABEL_NUSES' is only defined once the jump optimization 7158 phase is completed. It contains the number of times this label is 7159 referenced in the current function. 7160 7161 The field `LABEL_KIND' differentiates four different types of 7162 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY', 7163 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels 7164 that do not have type `LABEL_NORMAL' are "alternate entry points" 7165 to the current function. These may be static (visible only in the 7166 containing translation unit), global (exposed to all translation 7167 units), or weak (global, but can be overridden by another symbol 7168 with the same name). 7169 7170 Much of the compiler treats all four kinds of label identically. 7171 Some of it needs to know whether or not a label is an alternate 7172 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is 7173 provided. It is equivalent to testing whether `LABEL_KIND (label) 7174 == LABEL_NORMAL'. The only place that cares about the distinction 7175 between static, global, and weak alternate entry points, besides 7176 the front-end code that creates them, is the function 7177 `output_alternate_entry_point', in `final.c'. 7178 7179 To set the kind of a label, use the `SET_LABEL_KIND' macro. 7180 7181`barrier' 7182 Barriers are placed in the instruction stream when control cannot 7183 flow past them. They are placed after unconditional jump 7184 instructions to indicate that the jumps are unconditional and 7185 after calls to `volatile' functions, which do not return (e.g., 7186 `exit'). They contain no information beyond the three standard 7187 fields. 7188 7189`note' 7190 `note' insns are used to represent additional debugging and 7191 declarative information. They contain two nonstandard fields, an 7192 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a 7193 string accessed with `NOTE_SOURCE_FILE'. 7194 7195 If `NOTE_LINE_NUMBER' is positive, the note represents the 7196 position of a source line and `NOTE_SOURCE_FILE' is the source 7197 file name that the line came from. These notes control generation 7198 of line number data in the assembler output. 7199 7200 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a 7201 code with one of the following values (and `NOTE_SOURCE_FILE' must 7202 contain a null pointer): 7203 7204 `NOTE_INSN_DELETED' 7205 Such a note is completely ignorable. Some passes of the 7206 compiler delete insns by altering them into notes of this 7207 kind. 7208 7209 `NOTE_INSN_DELETED_LABEL' 7210 This marks what used to be a `code_label', but was not used 7211 for other purposes than taking its address and was 7212 transformed to mark that no code jumps to it. 7213 7214 `NOTE_INSN_BLOCK_BEG' 7215 `NOTE_INSN_BLOCK_END' 7216 These types of notes indicate the position of the beginning 7217 and end of a level of scoping of variable names. They 7218 control the output of debugging information. 7219 7220 `NOTE_INSN_EH_REGION_BEG' 7221 `NOTE_INSN_EH_REGION_END' 7222 These types of notes indicate the position of the beginning 7223 and end of a level of scoping for exception handling. 7224 `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note' 7225 of type `NOTE_INSN_DELETED_LABEL' is associated with the 7226 given region. 7227 7228 `NOTE_INSN_LOOP_BEG' 7229 `NOTE_INSN_LOOP_END' 7230 These types of notes indicate the position of the beginning 7231 and end of a `while' or `for' loop. They enable the loop 7232 optimizer to find loops quickly. 7233 7234 `NOTE_INSN_LOOP_CONT' 7235 Appears at the place in a loop that `continue' statements 7236 jump to. 7237 7238 `NOTE_INSN_LOOP_VTOP' 7239 This note indicates the place in a loop where the exit test 7240 begins for those loops in which the exit test has been 7241 duplicated. This position becomes another virtual start of 7242 the loop when considering loop invariants. 7243 7244 `NOTE_INSN_FUNCTION_END' 7245 Appears near the end of the function body, just before the 7246 label that `return' statements jump to (on machine where a 7247 single instruction does not suffice for returning). This 7248 note may be deleted by jump optimization. 7249 7250 `NOTE_INSN_SETJMP' 7251 Appears following each call to `setjmp' or a related function. 7252 7253 These codes are printed symbolically when they appear in debugging 7254 dumps. 7255 7256 The machine mode of an insn is normally `VOIDmode', but some phases 7257use the mode for various purposes. 7258 7259 The common subexpression elimination pass sets the mode of an insn to 7260`QImode' when it is the first insn in a block that has already been 7261processed. 7262 7263 The second Haifa scheduling pass, for targets that can multiple 7264issue, sets the mode of an insn to `TImode' when it is believed that the 7265instruction begins an issue group. That is, when the instruction 7266cannot issue simultaneously with the previous. This may be relied on 7267by later passes, in particular machine-dependent reorg. 7268 7269 Here is a table of the extra fields of `insn', `jump_insn' and 7270`call_insn' insns: 7271 7272`PATTERN (I)' 7273 An expression for the side effect performed by this insn. This 7274 must be one of the following codes: `set', `call', `use', 7275 `clobber', `return', `asm_input', `asm_output', `addr_vec', 7276 `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', 7277 `parallel', `cond_exec', or `sequence'. If it is a `parallel', 7278 each element of the `parallel' must be one these codes, except that 7279 `parallel' expressions cannot be nested and `addr_vec' and 7280 `addr_diff_vec' are not permitted inside a `parallel' expression. 7281 7282`INSN_CODE (I)' 7283 An integer that says which pattern in the machine description 7284 matches this insn, or -1 if the matching has not yet been 7285 attempted. 7286 7287 Such matching is never attempted and this field remains -1 on an 7288 insn whose pattern consists of a single `use', `clobber', 7289 `asm_input', `addr_vec' or `addr_diff_vec' expression. 7290 7291 Matching is also never attempted on insns that result from an `asm' 7292 statement. These contain at least one `asm_operands' expression. 7293 The function `asm_noperands' returns a non-negative value for such 7294 insns. 7295 7296 In the debugging output, this field is printed as a number 7297 followed by a symbolic representation that locates the pattern in 7298 the `md' file as some small positive or negative offset from a 7299 named pattern. 7300 7301`LOG_LINKS (I)' 7302 A list (chain of `insn_list' expressions) giving information about 7303 dependencies between instructions within a basic block. Neither a 7304 jump nor a label may come between the related insns. 7305 7306`REG_NOTES (I)' 7307 A list (chain of `expr_list' and `insn_list' expressions) giving 7308 miscellaneous information about the insn. It is often information 7309 pertaining to the registers used in this insn. 7310 7311 The `LOG_LINKS' field of an insn is a chain of `insn_list' 7312expressions. Each of these has two operands: the first is an insn, and 7313the second is another `insn_list' expression (the next one in the 7314chain). The last `insn_list' in the chain has a null pointer as second 7315operand. The significant thing about the chain is which insns appear 7316in it (as first operands of `insn_list' expressions). Their order is 7317not significant. 7318 7319 This list is originally set up by the flow analysis pass; it is a 7320null pointer until then. Flow only adds links for those data 7321dependencies which can be used for instruction combination. For each 7322insn, the flow analysis pass adds a link to insns which store into 7323registers values that are used for the first time in this insn. The 7324instruction scheduling pass adds extra links so that every dependence 7325will be represented. Links represent data dependencies, 7326antidependencies and output dependencies; the machine mode of the link 7327distinguishes these three types: antidependencies have mode 7328`REG_DEP_ANTI', output dependencies have mode `REG_DEP_OUTPUT', and 7329data dependencies have mode `VOIDmode'. 7330 7331 The `REG_NOTES' field of an insn is a chain similar to the 7332`LOG_LINKS' field but it includes `expr_list' expressions in addition 7333to `insn_list' expressions. There are several kinds of register notes, 7334which are distinguished by the machine mode, which in a register note 7335is really understood as being an `enum reg_note'. The first operand OP 7336of the note is data whose meaning depends on the kind of note. 7337 7338 The macro `REG_NOTE_KIND (X)' returns the kind of register note. 7339Its counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 7340register note type of X to be NEWKIND. 7341 7342 Register notes are of three classes: They may say something about an 7343input to an insn, they may say something about an output of an insn, or 7344they may create a linkage between two insns. There are also a set of 7345values that are only used in `LOG_LINKS'. 7346 7347 These register notes annotate inputs to an insn: 7348 7349`REG_DEAD' 7350 The value in OP dies in this insn; that is to say, altering the 7351 value immediately after this insn would not affect the future 7352 behavior of the program. 7353 7354 It does not follow that the register OP has no useful value after 7355 this insn since OP is not necessarily modified by this insn. 7356 Rather, no subsequent instruction uses the contents of OP. 7357 7358`REG_UNUSED' 7359 The register OP being set by this insn will not be used in a 7360 subsequent insn. This differs from a `REG_DEAD' note, which 7361 indicates that the value in an input will not be used subsequently. 7362 These two notes are independent; both may be present for the same 7363 register. 7364 7365`REG_INC' 7366 The register OP is incremented (or decremented; at this level 7367 there is no distinction) by an embedded side effect inside this 7368 insn. This means it appears in a `post_inc', `pre_inc', 7369 `post_dec' or `pre_dec' expression. 7370 7371`REG_NONNEG' 7372 The register OP is known to have a nonnegative value when this 7373 insn is reached. This is used so that decrement and branch until 7374 zero instructions, such as the m68k dbra, can be matched. 7375 7376 The `REG_NONNEG' note is added to insns only if the machine 7377 description has a `decrement_and_branch_until_zero' pattern. 7378 7379`REG_NO_CONFLICT' 7380 This insn does not cause a conflict between OP and the item being 7381 set by this insn even though it might appear that it does. In 7382 other words, if the destination register and OP could otherwise be 7383 assigned the same register, this insn does not prevent that 7384 assignment. 7385 7386 Insns with this note are usually part of a block that begins with a 7387 `clobber' insn specifying a multi-word pseudo register (which will 7388 be the output of the block), a group of insns that each set one 7389 word of the value and have the `REG_NO_CONFLICT' note attached, 7390 and a final insn that copies the output to itself with an attached 7391 `REG_EQUAL' note giving the expression being computed. This block 7392 is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the 7393 first and last insns, respectively. 7394 7395`REG_LABEL' 7396 This insn uses OP, a `code_label' or a `note' of type 7397 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a 7398 `jump_insn' that required the label to be held in a register. The 7399 presence of this note allows jump optimization to be aware that OP 7400 is, in fact, being used, and flow optimization to build an 7401 accurate flow graph. 7402 7403 The following notes describe attributes of outputs of an insn: 7404 7405`REG_EQUIV' 7406`REG_EQUAL' 7407 This note is only valid on an insn that sets only one register and 7408 indicates that that register will be equal to OP at run time; the 7409 scope of this equivalence differs between the two types of notes. 7410 The value which the insn explicitly copies into the register may 7411 look different from OP, but they will be equal at run time. If the 7412 output of the single `set' is a `strict_low_part' expression, the 7413 note refers to the register that is contained in `SUBREG_REG' of 7414 the `subreg' expression. 7415 7416 For `REG_EQUIV', the register is equivalent to OP throughout the 7417 entire function, and could validly be replaced in all its 7418 occurrences by OP. ("Validly" here refers to the data flow of the 7419 program; simple replacement may make some insns invalid.) For 7420 example, when a constant is loaded into a register that is never 7421 assigned any other value, this kind of note is used. 7422 7423 When a parameter is copied into a pseudo-register at entry to a 7424 function, a note of this kind records that the register is 7425 equivalent to the stack slot where the parameter was passed. 7426 Although in this case the register may be set by other insns, it 7427 is still valid to replace the register by the stack slot 7428 throughout the function. 7429 7430 A `REG_EQUIV' note is also used on an instruction which copies a 7431 register parameter into a pseudo-register at entry to a function, 7432 if there is a stack slot where that parameter could be stored. 7433 Although other insns may set the pseudo-register, it is valid for 7434 the compiler to replace the pseudo-register by stack slot 7435 throughout the function, provided the compiler ensures that the 7436 stack slot is properly initialized by making the replacement in 7437 the initial copy instruction as well. This is used on machines 7438 for which the calling convention allocates stack space for 7439 register parameters. See `REG_PARM_STACK_SPACE' in *Note Stack 7440 Arguments::. 7441 7442 In the case of `REG_EQUAL', the register that is set by this insn 7443 will be equal to OP at run time at the end of this insn but not 7444 necessarily elsewhere in the function. In this case, OP is 7445 typically an arithmetic expression. For example, when a sequence 7446 of insns such as a library call is used to perform an arithmetic 7447 operation, this kind of note is attached to the insn that produces 7448 or copies the final value. 7449 7450 These two notes are used in different ways by the compiler passes. 7451 `REG_EQUAL' is used by passes prior to register allocation (such as 7452 common subexpression elimination and loop optimization) to tell 7453 them how to think of that value. `REG_EQUIV' notes are used by 7454 register allocation to indicate that there is an available 7455 substitute expression (either a constant or a `mem' expression for 7456 the location of a parameter on the stack) that may be used in 7457 place of a register if insufficient registers are available. 7458 7459 Except for stack homes for parameters, which are indicated by a 7460 `REG_EQUIV' note and are not useful to the early optimization 7461 passes and pseudo registers that are equivalent to a memory 7462 location throughout their entire life, which is not detected until 7463 later in the compilation, all equivalences are initially indicated 7464 by an attached `REG_EQUAL' note. In the early stages of register 7465 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note 7466 if OP is a constant and the insn represents the only set of its 7467 destination register. 7468 7469 Thus, compiler passes prior to register allocation need only check 7470 for `REG_EQUAL' notes and passes subsequent to register allocation 7471 need only check for `REG_EQUIV' notes. 7472 7473 These notes describe linkages between insns. They occur in pairs: 7474one insn has one of a pair of notes that points to a second insn, which 7475has the inverse note pointing back to the first insn. 7476 7477`REG_RETVAL' 7478 This insn copies the value of a multi-insn sequence (for example, a 7479 library call), and OP is the first insn of the sequence (for a 7480 library call, the first insn that was generated to set up the 7481 arguments for the library call). 7482 7483 Loop optimization uses this note to treat such a sequence as a 7484 single operation for code motion purposes and flow analysis uses 7485 this note to delete such sequences whose results are dead. 7486 7487 A `REG_EQUAL' note will also usually be attached to this insn to 7488 provide the expression being computed by the sequence. 7489 7490 These notes will be deleted after reload, since they are no longer 7491 accurate or useful. 7492 7493`REG_LIBCALL' 7494 This is the inverse of `REG_RETVAL': it is placed on the first 7495 insn of a multi-insn sequence, and it points to the last one. 7496 7497 These notes are deleted after reload, since they are no longer 7498 useful or accurate. 7499 7500`REG_CC_SETTER' 7501`REG_CC_USER' 7502 On machines that use `cc0', the insns which set and use `cc0' set 7503 and use `cc0' are adjacent. However, when branch delay slot 7504 filling is done, this may no longer be true. In this case a 7505 `REG_CC_USER' note will be placed on the insn setting `cc0' to 7506 point to the insn using `cc0' and a `REG_CC_SETTER' note will be 7507 placed on the insn using `cc0' to point to the insn setting `cc0'. 7508 7509 These values are only used in the `LOG_LINKS' field, and indicate 7510the type of dependency that each link represents. Links which indicate 7511a data dependence (a read after write dependence) do not use any code, 7512they simply have mode `VOIDmode', and are printed without any 7513descriptive text. 7514 7515`REG_DEP_ANTI' 7516 This indicates an anti dependence (a write after read dependence). 7517 7518`REG_DEP_OUTPUT' 7519 This indicates an output dependence (a write after write 7520 dependence). 7521 7522 These notes describe information gathered from gcov profile data. 7523They are stored in the `REG_NOTES' field of an insn as an `expr_list'. 7524 7525`REG_BR_PROB' 7526 This is used to specify the ratio of branches to non-branches of a 7527 branch insn according to the profile data. The value is stored as 7528 a value between 0 and REG_BR_PROB_BASE; larger values indicate a 7529 higher probability that the branch will be taken. 7530 7531`REG_BR_PRED' 7532 These notes are found in JUMP insns after delayed branch scheduling 7533 has taken place. They indicate both the direction and the 7534 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 7535 values. 7536 7537`REG_FRAME_RELATED_EXPR' 7538 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 7539 expression is used in place of the actual insn pattern. This is 7540 done in cases where the pattern is either complex or misleading. 7541 7542 For convenience, the machine mode in an `insn_list' or `expr_list' 7543is printed using these symbolic codes in debugging dumps. 7544 7545 The only difference between the expression codes `insn_list' and 7546`expr_list' is that the first operand of an `insn_list' is assumed to 7547be an insn and is printed in debugging dumps as the insn's unique id; 7548the first operand of an `expr_list' is printed in the ordinary way as 7549an expression. 7550 7551 7552File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 7553 75549.19 RTL Representation of Function-Call Insns 7555============================================== 7556 7557Insns that call subroutines have the RTL expression code `call_insn'. 7558These insns must satisfy special rules, and their bodies must use a 7559special RTL expression code, `call'. 7560 7561 A `call' expression has two operands, as follows: 7562 7563 (call (mem:FM ADDR) NBYTES) 7564 7565Here NBYTES is an operand that represents the number of bytes of 7566argument data being passed to the subroutine, FM is a machine mode 7567(which must equal as the definition of the `FUNCTION_MODE' macro in the 7568machine description) and ADDR represents the address of the subroutine. 7569 7570 For a subroutine that returns no value, the `call' expression as 7571shown above is the entire body of the insn, except that the insn might 7572also contain `use' or `clobber' expressions. 7573 7574 For a subroutine that returns a value whose mode is not `BLKmode', 7575the value is returned in a hard register. If this register's number is 7576R, then the body of the call insn looks like this: 7577 7578 (set (reg:M R) 7579 (call (mem:FM ADDR) NBYTES)) 7580 7581This RTL expression makes it clear (to the optimizer passes) that the 7582appropriate register receives a useful value in this insn. 7583 7584 When a subroutine returns a `BLKmode' value, it is handled by 7585passing to the subroutine the address of a place to store the value. 7586So the call insn itself does not "return" any value, and it has the 7587same RTL form as a call that returns nothing. 7588 7589 On some machines, the call instruction itself clobbers some register, 7590for example to contain the return address. `call_insn' insns on these 7591machines should have a body which is a `parallel' that contains both 7592the `call' expression and `clobber' expressions that indicate which 7593registers are destroyed. Similarly, if the call instruction requires 7594some register other than the stack pointer that is not explicitly 7595mentioned it its RTL, a `use' subexpression should mention that 7596register. 7597 7598 Functions that are called are assumed to modify all registers listed 7599in the configuration macro `CALL_USED_REGISTERS' (*note Register 7600Basics::) and, with the exception of `const' functions and library 7601calls, to modify all of memory. 7602 7603 Insns containing just `use' expressions directly precede the 7604`call_insn' insn to indicate which registers contain inputs to the 7605function. Similarly, if registers other than those in 7606`CALL_USED_REGISTERS' are clobbered by the called function, insns 7607containing a single `clobber' follow immediately after the call to 7608indicate which registers. 7609 7610 7611File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 7612 76139.20 Structure Sharing Assumptions 7614================================== 7615 7616The compiler assumes that certain kinds of RTL expressions are unique; 7617there do not exist two distinct objects representing the same value. 7618In other cases, it makes an opposite assumption: that no RTL expression 7619object of a certain kind appears in more than one place in the 7620containing structure. 7621 7622 These assumptions refer to a single function; except for the RTL 7623objects that describe global variables and external functions, and a 7624few standard objects such as small integer constants, no RTL objects 7625are common to two functions. 7626 7627 * Each pseudo-register has only a single `reg' object to represent 7628 it, and therefore only a single machine mode. 7629 7630 * For any symbolic label, there is only one `symbol_ref' object 7631 referring to it. 7632 7633 * All `const_int' expressions with equal values are shared. 7634 7635 * There is only one `pc' expression. 7636 7637 * There is only one `cc0' expression. 7638 7639 * There is only one `const_double' expression with value 0 for each 7640 floating point mode. Likewise for values 1 and 2. 7641 7642 * There is only one `const_vector' expression with value 0 for each 7643 vector mode, be it an integer or a double constant vector. 7644 7645 * No `label_ref' or `scratch' appears in more than one place in the 7646 RTL structure; in other words, it is safe to do a tree-walk of all 7647 the insns in the function and assume that each time a `label_ref' 7648 or `scratch' is seen it is distinct from all others that are seen. 7649 7650 * Only one `mem' object is normally created for each static variable 7651 or stack slot, so these objects are frequently shared in all the 7652 places they appear. However, separate but equal objects for these 7653 variables are occasionally made. 7654 7655 * When a single `asm' statement has multiple output operands, a 7656 distinct `asm_operands' expression is made for each output operand. 7657 However, these all share the vector which contains the sequence of 7658 input operands. This sharing is used later on to test whether two 7659 `asm_operands' expressions come from the same statement, so all 7660 optimizations must carefully preserve the sharing if they copy the 7661 vector at all. 7662 7663 * No RTL object appears in more than one place in the RTL structure 7664 except as described above. Many passes of the compiler rely on 7665 this by assuming that they can modify RTL objects in place without 7666 unwanted side-effects on other insns. 7667 7668 * During initial RTL generation, shared structure is freely 7669 introduced. After all the RTL for a function has been generated, 7670 all shared structure is copied by `unshare_all_rtl' in 7671 `emit-rtl.c', after which the above rules are guaranteed to be 7672 followed. 7673 7674 * During the combiner pass, shared structure within an insn can exist 7675 temporarily. However, the shared structure is copied before the 7676 combiner is finished with the insn. This is done by calling 7677 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'. 7678 7679 7680File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 7681 76829.21 Reading RTL 7683================ 7684 7685To read an RTL object from a file, call `read_rtx'. It takes one 7686argument, a stdio stream, and returns a single RTL object. This routine 7687is defined in `read-rtl.c'. It is not available in the compiler 7688itself, only the various programs that generate the compiler back end 7689from the machine description. 7690 7691 People frequently have the idea of using RTL stored as text in a 7692file as an interface between a language front end and the bulk of GCC. 7693This idea is not feasible. 7694 7695 GCC was designed to use RTL internally only. Correct RTL for a given 7696program is very dependent on the particular target machine. And the RTL 7697does not contain all the information about the program. 7698 7699 The proper way to interface GCC to a new language front end is with 7700the "tree" data structure, described in the files `tree.h' and 7701`tree.def'. The documentation for this structure (*note Trees::) is 7702incomplete. 7703 7704 7705File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: RTL, Up: Top 7706 770710 Machine Descriptions 7708*********************** 7709 7710A machine description has two parts: a file of instruction patterns 7711(`.md' file) and a C header file of macro definitions. 7712 7713 The `.md' file for a target machine contains a pattern for each 7714instruction that the target machine supports (or at least each 7715instruction that is worth telling the compiler about). It may also 7716contain comments. A semicolon causes the rest of the line to be a 7717comment, unless the semicolon is inside a quoted string. 7718 7719 See the next chapter for information on the C header file. 7720 7721* Menu: 7722 7723* Overview:: How the machine description is used. 7724* Patterns:: How to write instruction patterns. 7725* Example:: An explained example of a `define_insn' pattern. 7726* RTL Template:: The RTL template defines what insns match a pattern. 7727* Output Template:: The output template says how to make assembler code 7728 from such an insn. 7729* Output Statement:: For more generality, write C code to output 7730 the assembler code. 7731* Constraints:: When not all operands are general operands. 7732* Standard Names:: Names mark patterns to use for code generation. 7733* Pattern Ordering:: When the order of patterns makes a difference. 7734* Dependent Patterns:: Having one pattern may make you need another. 7735* Jump Patterns:: Special considerations for patterns for jump insns. 7736* Looping Patterns:: How to define patterns for special looping insns. 7737* Insn Canonicalizations::Canonicalization of Instructions 7738* Expander Definitions::Generating a sequence of several RTL insns 7739 for a standard operation. 7740* Insn Splitting:: Splitting Instructions into Multiple Instructions. 7741* Including Patterns:: Including Patterns in Machine Descriptions. 7742* Peephole Definitions::Defining machine-specific peephole optimizations. 7743* Insn Attributes:: Specifying the value of attributes for generated insns. 7744* Conditional Execution::Generating `define_insn' patterns for 7745 predication. 7746* Constant Definitions::Defining symbolic constants that can be used in the 7747 md file. 7748 7749 7750File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 7751 775210.1 Overview of How the Machine Description is Used 7753==================================================== 7754 7755There are three main conversions that happen in the compiler: 7756 7757 1. The front end reads the source code and builds a parse tree. 7758 7759 2. The parse tree is used to generate an RTL insn list based on named 7760 instruction patterns. 7761 7762 3. The insn list is matched against the RTL templates to produce 7763 assembler code. 7764 7765 7766 For the generate pass, only the names of the insns matter, from 7767either a named `define_insn' or a `define_expand'. The compiler will 7768choose the pattern with the right name and apply the operands according 7769to the documentation later in this chapter, without regard for the RTL 7770template or operand constraints. Note that the names the compiler looks 7771for are hard-coded in the compiler--it will ignore unnamed patterns and 7772patterns with names it doesn't know about, but if you don't provide a 7773named pattern it needs, it will abort. 7774 7775 If a `define_insn' is used, the template given is inserted into the 7776insn list. If a `define_expand' is used, one of three things happens, 7777based on the condition logic. The condition logic may manually create 7778new insns for the insn list, say via `emit_insn()', and invoke `DONE'. 7779For certain named patterns, it may invoke `FAIL' to tell the compiler 7780to use an alternate way of performing that task. If it invokes neither 7781`DONE' nor `FAIL', the template given in the pattern is inserted, as if 7782the `define_expand' were a `define_insn'. 7783 7784 Once the insn list is generated, various optimization passes convert, 7785replace, and rearrange the insns in the insn list. This is where the 7786`define_split' and `define_peephole' patterns get used, for example. 7787 7788 Finally, the insn list's RTL is matched up with the RTL templates in 7789the `define_insn' patterns, and those patterns are used to emit the 7790final assembly code. For this purpose, each named `define_insn' acts 7791like it's unnamed, since the names are ignored. 7792 7793 7794File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 7795 779610.2 Everything about Instruction Patterns 7797========================================== 7798 7799Each instruction pattern contains an incomplete RTL expression, with 7800pieces to be filled in later, operand constraints that restrict how the 7801pieces can be filled in, and an output pattern or C code to generate 7802the assembler output, all wrapped up in a `define_insn' expression. 7803 7804 A `define_insn' is an RTL expression containing four or five 7805operands: 7806 7807 1. An optional name. The presence of a name indicate that this 7808 instruction pattern can perform a certain standard job for the 7809 RTL-generation pass of the compiler. This pass knows certain 7810 names and will use the instruction patterns with those names, if 7811 the names are defined in the machine description. 7812 7813 The absence of a name is indicated by writing an empty string 7814 where the name should go. Nameless instruction patterns are never 7815 used for generating RTL code, but they may permit several simpler 7816 insns to be combined later on. 7817 7818 Names that are not thus known and used in RTL-generation have no 7819 effect; they are equivalent to no name at all. 7820 7821 For the purpose of debugging the compiler, you may also specify a 7822 name beginning with the `*' character. Such a name is used only 7823 for identifying the instruction in RTL dumps; it is entirely 7824 equivalent to having a nameless pattern for all other purposes. 7825 7826 2. The "RTL template" (*note RTL Template::) is a vector of incomplete 7827 RTL expressions which show what the instruction should look like. 7828 It is incomplete because it may contain `match_operand', 7829 `match_operator', and `match_dup' expressions that stand for 7830 operands of the instruction. 7831 7832 If the vector has only one element, that element is the template 7833 for the instruction pattern. If the vector has multiple elements, 7834 then the instruction pattern is a `parallel' expression containing 7835 the elements described. 7836 7837 3. A condition. This is a string which contains a C expression that 7838 is the final test to decide whether an insn body matches this 7839 pattern. 7840 7841 For a named pattern, the condition (if present) may not depend on 7842 the data in the insn being matched, but only the 7843 target-machine-type flags. The compiler needs to test these 7844 conditions during initialization in order to learn exactly which 7845 named instructions are available in a particular run. 7846 7847 For nameless patterns, the condition is applied only when matching 7848 an individual insn, and only after the insn has matched the 7849 pattern's recognition template. The insn's operands may be found 7850 in the vector `operands'. For an insn where the condition has 7851 once matched, it can't be used to control register allocation, for 7852 example by excluding certain hard registers or hard register 7853 combinations. 7854 7855 4. The "output template": a string that says how to output matching 7856 insns as assembler code. `%' in this string specifies where to 7857 substitute the value of an operand. *Note Output Template::. 7858 7859 When simple substitution isn't general enough, you can specify a 7860 piece of C code to compute the output. *Note Output Statement::. 7861 7862 5. Optionally, a vector containing the values of attributes for insns 7863 matching this pattern. *Note Insn Attributes::. 7864 7865 7866File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 7867 786810.3 Example of `define_insn' 7869============================= 7870 7871Here is an actual example of an instruction pattern, for the 787268000/68020. 7873 7874 (define_insn "tstsi" 7875 [(set (cc0) 7876 (match_operand:SI 0 "general_operand" "rm"))] 7877 "" 7878 "* 7879 { 7880 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 7881 return \"tstl %0\"; 7882 return \"cmpl #0,%0\"; 7883 }") 7884 7885This can also be written using braced strings: 7886 7887 (define_insn "tstsi" 7888 [(set (cc0) 7889 (match_operand:SI 0 "general_operand" "rm"))] 7890 "" 7891 { 7892 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 7893 return "tstl %0"; 7894 return "cmpl #0,%0"; 7895 }) 7896 7897 This is an instruction that sets the condition codes based on the 7898value of a general operand. It has no condition, so any insn whose RTL 7899description has the form shown may be handled according to this 7900pattern. The name `tstsi' means "test a `SImode' value" and tells the 7901RTL generation pass that, when it is necessary to test such a value, an 7902insn to do so can be constructed using this pattern. 7903 7904 The output control string is a piece of C code which chooses which 7905output template to return based on the kind of operand and the specific 7906type of CPU for which code is being generated. 7907 7908 `"rm"' is an operand constraint. Its meaning is explained below. 7909 7910 7911File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 7912 791310.4 RTL Template 7914================= 7915 7916The RTL template is used to define which insns match the particular 7917pattern and how to find their operands. For named patterns, the RTL 7918template also says how to construct an insn from specified operands. 7919 7920 Construction involves substituting specified operands into a copy of 7921the template. Matching involves determining the values that serve as 7922the operands in the insn being matched. Both of these activities are 7923controlled by special expression types that direct matching and 7924substitution of the operands. 7925 7926`(match_operand:M N PREDICATE CONSTRAINT)' 7927 This expression is a placeholder for operand number N of the insn. 7928 When constructing an insn, operand number N will be substituted 7929 at this point. When matching an insn, whatever appears at this 7930 position in the insn will be taken as operand number N; but it 7931 must satisfy PREDICATE or this instruction pattern will not match 7932 at all. 7933 7934 Operand numbers must be chosen consecutively counting from zero in 7935 each instruction pattern. There may be only one `match_operand' 7936 expression in the pattern for each operand number. Usually 7937 operands are numbered in the order of appearance in `match_operand' 7938 expressions. In the case of a `define_expand', any operand numbers 7939 used only in `match_dup' expressions have higher values than all 7940 other operand numbers. 7941 7942 PREDICATE is a string that is the name of a C function that 7943 accepts two arguments, an expression and a machine mode. During 7944 matching, the function will be called with the putative operand as 7945 the expression and M as the mode argument (if M is not specified, 7946 `VOIDmode' will be used, which normally causes PREDICATE to accept 7947 any mode). If it returns zero, this instruction pattern fails to 7948 match. PREDICATE may be an empty string; then it means no test is 7949 to be done on the operand, so anything which occurs in this 7950 position is valid. 7951 7952 Most of the time, PREDICATE will reject modes other than M--but 7953 not always. For example, the predicate `address_operand' uses M 7954 as the mode of memory ref that the address should be valid for. 7955 Many predicates accept `const_int' nodes even though their mode is 7956 `VOIDmode'. 7957 7958 CONSTRAINT controls reloading and the choice of the best register 7959 class to use for a value, as explained later (*note Constraints::). 7960 7961 People are often unclear on the difference between the constraint 7962 and the predicate. The predicate helps decide whether a given 7963 insn matches the pattern. The constraint plays no role in this 7964 decision; instead, it controls various decisions in the case of an 7965 insn which does match. 7966 7967 On CISC machines, the most common PREDICATE is 7968 `"general_operand"'. This function checks that the putative 7969 operand is either a constant, a register or a memory reference, 7970 and that it is valid for mode M. 7971 7972 For an operand that must be a register, PREDICATE should be 7973 `"register_operand"'. Using `"general_operand"' would be valid, 7974 since the reload pass would copy any non-register operands through 7975 registers, but this would make GCC do extra work, it would prevent 7976 invariant operands (such as constant) from being removed from 7977 loops, and it would prevent the register allocator from doing the 7978 best possible job. On RISC machines, it is usually most efficient 7979 to allow PREDICATE to accept only objects that the constraints 7980 allow. 7981 7982 For an operand that must be a constant, you must be sure to either 7983 use `"immediate_operand"' for PREDICATE, or make the instruction 7984 pattern's extra condition require a constant, or both. You cannot 7985 expect the constraints to do this work! If the constraints allow 7986 only constants, but the predicate allows something else, the 7987 compiler will crash when that case arises. 7988 7989`(match_scratch:M N CONSTRAINT)' 7990 This expression is also a placeholder for operand number N and 7991 indicates that operand must be a `scratch' or `reg' expression. 7992 7993 When matching patterns, this is equivalent to 7994 7995 (match_operand:M N "scratch_operand" PRED) 7996 7997 but, when generating RTL, it produces a (`scratch':M) expression. 7998 7999 If the last few expressions in a `parallel' are `clobber' 8000 expressions whose operands are either a hard register or 8001 `match_scratch', the combiner can add or delete them when 8002 necessary. *Note Side Effects::. 8003 8004`(match_dup N)' 8005 This expression is also a placeholder for operand number N. It is 8006 used when the operand needs to appear more than once in the insn. 8007 8008 In construction, `match_dup' acts just like `match_operand': the 8009 operand is substituted into the insn being constructed. But in 8010 matching, `match_dup' behaves differently. It assumes that operand 8011 number N has already been determined by a `match_operand' 8012 appearing earlier in the recognition template, and it matches only 8013 an identical-looking expression. 8014 8015 Note that `match_dup' should not be used to tell the compiler that 8016 a particular register is being used for two operands (example: 8017 `add' that adds one register to another; the second register is 8018 both an input operand and the output operand). Use a matching 8019 constraint (*note Simple Constraints::) for those. `match_dup' is 8020 for the cases where one operand is used in two places in the 8021 template, such as an instruction that computes both a quotient and 8022 a remainder, where the opcode takes two input operands but the RTL 8023 template has to refer to each of those twice; once for the 8024 quotient pattern and once for the remainder pattern. 8025 8026`(match_operator:M N PREDICATE [OPERANDS...])' 8027 This pattern is a kind of placeholder for a variable RTL expression 8028 code. 8029 8030 When constructing an insn, it stands for an RTL expression whose 8031 expression code is taken from that of operand N, and whose 8032 operands are constructed from the patterns OPERANDS. 8033 8034 When matching an expression, it matches an expression if the 8035 function PREDICATE returns nonzero on that expression _and_ the 8036 patterns OPERANDS match the operands of the expression. 8037 8038 Suppose that the function `commutative_operator' is defined as 8039 follows, to match any expression whose operator is one of the 8040 commutative arithmetic operators of RTL and whose mode is MODE: 8041 8042 int 8043 commutative_operator (x, mode) 8044 rtx x; 8045 enum machine_mode mode; 8046 { 8047 enum rtx_code code = GET_CODE (x); 8048 if (GET_MODE (x) != mode) 8049 return 0; 8050 return (GET_RTX_CLASS (code) == 'c' 8051 || code == EQ || code == NE); 8052 } 8053 8054 Then the following pattern will match any RTL expression consisting 8055 of a commutative operator applied to two general operands: 8056 8057 (match_operator:SI 3 "commutative_operator" 8058 [(match_operand:SI 1 "general_operand" "g") 8059 (match_operand:SI 2 "general_operand" "g")]) 8060 8061 Here the vector `[OPERANDS...]' contains two patterns because the 8062 expressions to be matched all contain two operands. 8063 8064 When this pattern does match, the two operands of the commutative 8065 operator are recorded as operands 1 and 2 of the insn. (This is 8066 done by the two instances of `match_operand'.) Operand 3 of the 8067 insn will be the entire commutative expression: use `GET_CODE 8068 (operands[3])' to see which commutative operator was used. 8069 8070 The machine mode M of `match_operator' works like that of 8071 `match_operand': it is passed as the second argument to the 8072 predicate function, and that function is solely responsible for 8073 deciding whether the expression to be matched "has" that mode. 8074 8075 When constructing an insn, argument 3 of the gen-function will 8076 specify the operation (i.e. the expression code) for the 8077 expression to be made. It should be an RTL expression, whose 8078 expression code is copied into a new expression whose operands are 8079 arguments 1 and 2 of the gen-function. The subexpressions of 8080 argument 3 are not used; only its expression code matters. 8081 8082 When `match_operator' is used in a pattern for matching an insn, 8083 it usually best if the operand number of the `match_operator' is 8084 higher than that of the actual operands of the insn. This improves 8085 register allocation because the register allocator often looks at 8086 operands 1 and 2 of insns to see if it can do register tying. 8087 8088 There is no way to specify constraints in `match_operator'. The 8089 operand of the insn which corresponds to the `match_operator' 8090 never has any constraints because it is never reloaded as a whole. 8091 However, if parts of its OPERANDS are matched by `match_operand' 8092 patterns, those parts may have constraints of their own. 8093 8094`(match_op_dup:M N[OPERANDS...])' 8095 Like `match_dup', except that it applies to operators instead of 8096 operands. When constructing an insn, operand number N will be 8097 substituted at this point. But in matching, `match_op_dup' behaves 8098 differently. It assumes that operand number N has already been 8099 determined by a `match_operator' appearing earlier in the 8100 recognition template, and it matches only an identical-looking 8101 expression. 8102 8103`(match_parallel N PREDICATE [SUBPAT...])' 8104 This pattern is a placeholder for an insn that consists of a 8105 `parallel' expression with a variable number of elements. This 8106 expression should only appear at the top level of an insn pattern. 8107 8108 When constructing an insn, operand number N will be substituted at 8109 this point. When matching an insn, it matches if the body of the 8110 insn is a `parallel' expression with at least as many elements as 8111 the vector of SUBPAT expressions in the `match_parallel', if each 8112 SUBPAT matches the corresponding element of the `parallel', _and_ 8113 the function PREDICATE returns nonzero on the `parallel' that is 8114 the body of the insn. It is the responsibility of the predicate 8115 to validate elements of the `parallel' beyond those listed in the 8116 `match_parallel'. 8117 8118 A typical use of `match_parallel' is to match load and store 8119 multiple expressions, which can contain a variable number of 8120 elements in a `parallel'. For example, 8121 8122 (define_insn "" 8123 [(match_parallel 0 "load_multiple_operation" 8124 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 8125 (match_operand:SI 2 "memory_operand" "m")) 8126 (use (reg:SI 179)) 8127 (clobber (reg:SI 179))])] 8128 "" 8129 "loadm 0,0,%1,%2") 8130 8131 This example comes from `a29k.md'. The function 8132 `load_multiple_operation' is defined in `a29k.c' and checks that 8133 subsequent elements in the `parallel' are the same as the `set' in 8134 the pattern, except that they are referencing subsequent registers 8135 and memory locations. 8136 8137 An insn that matches this pattern might look like: 8138 8139 (parallel 8140 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 8141 (use (reg:SI 179)) 8142 (clobber (reg:SI 179)) 8143 (set (reg:SI 21) 8144 (mem:SI (plus:SI (reg:SI 100) 8145 (const_int 4)))) 8146 (set (reg:SI 22) 8147 (mem:SI (plus:SI (reg:SI 100) 8148 (const_int 8))))]) 8149 8150`(match_par_dup N [SUBPAT...])' 8151 Like `match_op_dup', but for `match_parallel' instead of 8152 `match_operator'. 8153 8154`(match_insn PREDICATE)' 8155 Match a complete insn. Unlike the other `match_*' recognizers, 8156 `match_insn' does not take an operand number. 8157 8158 The machine mode M of `match_insn' works like that of 8159 `match_operand': it is passed as the second argument to the 8160 predicate function, and that function is solely responsible for 8161 deciding whether the expression to be matched "has" that mode. 8162 8163`(match_insn2 N PREDICATE)' 8164 Match a complete insn. 8165 8166 The machine mode M of `match_insn2' works like that of 8167 `match_operand': it is passed as the second argument to the 8168 predicate function, and that function is solely responsible for 8169 deciding whether the expression to be matched "has" that mode. 8170 8171 8172 8173File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 8174 817510.5 Output Templates and Operand Substitution 8176============================================== 8177 8178The "output template" is a string which specifies how to output the 8179assembler code for an instruction pattern. Most of the template is a 8180fixed string which is output literally. The character `%' is used to 8181specify where to substitute an operand; it can also be used to identify 8182places where different variants of the assembler require different 8183syntax. 8184 8185 In the simplest case, a `%' followed by a digit N says to output 8186operand N at that point in the string. 8187 8188 `%' followed by a letter and a digit says to output an operand in an 8189alternate fashion. Four letters have standard, built-in meanings 8190described below. The machine description macro `PRINT_OPERAND' can 8191define additional letters with nonstandard meanings. 8192 8193 `%cDIGIT' can be used to substitute an operand that is a constant 8194value without the syntax that normally indicates an immediate operand. 8195 8196 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 8197negated before printing. 8198 8199 `%aDIGIT' can be used to substitute an operand as if it were a 8200memory reference, with the actual operand treated as the address. This 8201may be useful when outputting a "load address" instruction, because 8202often the assembler syntax for such an instruction requires you to 8203write the operand as if it were a memory reference. 8204 8205 `%lDIGIT' is used to substitute a `label_ref' into a jump 8206instruction. 8207 8208 `%=' outputs a number which is unique to each instruction in the 8209entire compilation. This is useful for making local labels to be 8210referred to more than once in a single template that generates multiple 8211assembler instructions. 8212 8213 `%' followed by a punctuation character specifies a substitution that 8214does not use an operand. Only one case is standard: `%%' outputs a `%' 8215into the assembler code. Other nonstandard cases can be defined in the 8216`PRINT_OPERAND' macro. You must also define which punctuation 8217characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 8218 8219 The template may generate multiple assembler instructions. Write 8220the text for the instructions, with `\;' between them. 8221 8222 When the RTL contains two operands which are required by constraint 8223to match each other, the output template must refer only to the 8224lower-numbered operand. Matching operands are not always identical, 8225and the rest of the compiler arranges to put the proper RTL expression 8226for printing into the lower-numbered operand. 8227 8228 One use of nonstandard letters or punctuation following `%' is to 8229distinguish between different assembler languages for the same machine; 8230for example, Motorola syntax versus MIT syntax for the 68000. Motorola 8231syntax requires periods in most opcode names, while MIT syntax does 8232not. For example, the opcode `movel' in MIT syntax is `move.l' in 8233Motorola syntax. The same file of patterns is used for both kinds of 8234output syntax, but the character sequence `%.' is used in each place 8235where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 8236Motorola syntax defines the sequence to output a period; the macro for 8237MIT syntax defines it to do nothing. 8238 8239 As a special case, a template consisting of the single character `#' 8240instructs the compiler to first split the insn, and then output the 8241resulting instructions separately. This helps eliminate redundancy in 8242the output templates. If you have a `define_insn' that needs to emit 8243multiple assembler instructions, and there is an matching `define_split' 8244already defined, then you can simply use `#' as the output template 8245instead of writing an output template that emits the multiple assembler 8246instructions. 8247 8248 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct 8249of the form `{option0|option1|option2}' in the templates. These 8250describe multiple variants of assembler language syntax. *Note 8251Instruction Output::. 8252 8253 8254File: gccint.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc 8255 825610.6 C Statements for Assembler Output 8257====================================== 8258 8259Often a single fixed template string cannot produce correct and 8260efficient assembler code for all the cases that are recognized by a 8261single instruction pattern. For example, the opcodes may depend on the 8262kinds of operands; or some unfortunate combinations of operands may 8263require extra machine instructions. 8264 8265 If the output control string starts with a `@', then it is actually 8266a series of templates, each on a separate line. (Blank lines and 8267leading spaces and tabs are ignored.) The templates correspond to the 8268pattern's constraint alternatives (*note Multi-Alternative::). For 8269example, if a target machine has a two-address add instruction `addr' 8270to add into a register and another `addm' to add a register to memory, 8271you might write this pattern: 8272 8273 (define_insn "addsi3" 8274 [(set (match_operand:SI 0 "general_operand" "=r,m") 8275 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 8276 (match_operand:SI 2 "general_operand" "g,r")))] 8277 "" 8278 "@ 8279 addr %2,%0 8280 addm %2,%0") 8281 8282 If the output control string starts with a `*', then it is not an 8283output template but rather a piece of C program that should compute a 8284template. It should execute a `return' statement to return the 8285template-string you want. Most such templates use C string literals, 8286which require doublequote characters to delimit them. To include these 8287doublequote characters in the string, prefix each one with `\'. 8288 8289 If the output control string is written as a brace block instead of a 8290double-quoted string, it is automatically assumed to be C code. In that 8291case, it is not necessary to put in a leading asterisk, or to escape the 8292doublequotes surrounding C string literals. 8293 8294 The operands may be found in the array `operands', whose C data type 8295is `rtx []'. 8296 8297 It is very common to select different ways of generating assembler 8298code based on whether an immediate operand is within a certain range. 8299Be careful when doing this, because the result of `INTVAL' is an 8300integer on the host machine. If the host machine has more bits in an 8301`int' than the target machine has in the mode in which the constant 8302will be used, then some of the bits you get from `INTVAL' will be 8303superfluous. For proper results, you must carefully disregard the 8304values of those bits. 8305 8306 It is possible to output an assembler instruction and then go on to 8307output or compute more of them, using the subroutine `output_asm_insn'. 8308This receives two arguments: a template-string and a vector of 8309operands. The vector may be `operands', or it may be another array of 8310`rtx' that you declare locally and initialize yourself. 8311 8312 When an insn pattern has multiple alternatives in its constraints, 8313often the appearance of the assembler code is determined mostly by 8314which alternative was matched. When this is so, the C code can test 8315the variable `which_alternative', which is the ordinal number of the 8316alternative that was actually satisfied (0 for the first, 1 for the 8317second alternative, etc.). 8318 8319 For example, suppose there are two opcodes for storing zero, `clrreg' 8320for registers and `clrmem' for memory locations. Here is how a pattern 8321could use `which_alternative' to choose between them: 8322 8323 (define_insn "" 8324 [(set (match_operand:SI 0 "general_operand" "=r,m") 8325 (const_int 0))] 8326 "" 8327 { 8328 return (which_alternative == 0 8329 ? "clrreg %0" : "clrmem %0"); 8330 }) 8331 8332 The example above, where the assembler code to generate was _solely_ 8333determined by the alternative, could also have been specified as 8334follows, having the output control string start with a `@': 8335 8336 (define_insn "" 8337 [(set (match_operand:SI 0 "general_operand" "=r,m") 8338 (const_int 0))] 8339 "" 8340 "@ 8341 clrreg %0 8342 clrmem %0") 8343 8344 8345File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc 8346 834710.7 Operand Constraints 8348======================== 8349 8350Each `match_operand' in an instruction pattern can specify a constraint 8351for the type of operands allowed. Constraints can say whether an 8352operand may be in a register, and which kinds of register; whether the 8353operand can be a memory reference, and which kinds of address; whether 8354the operand may be an immediate constant, and which possible values it 8355may have. Constraints can also require two operands to match. 8356 8357* Menu: 8358 8359* Simple Constraints:: Basic use of constraints. 8360* Multi-Alternative:: When an insn has two alternative constraint-patterns. 8361* Class Preferences:: Constraints guide which hard register to put things in. 8362* Modifiers:: More precise control over effects of constraints. 8363* Machine Constraints:: Existing constraints for some particular machines. 8364 8365 8366File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 8367 836810.7.1 Simple Constraints 8369------------------------- 8370 8371The simplest kind of constraint is a string full of letters, each of 8372which describes one kind of operand that is permitted. Here are the 8373letters that are allowed: 8374 8375whitespace 8376 Whitespace characters are ignored and can be inserted at any 8377 position except the first. This enables each alternative for 8378 different operands to be visually aligned in the machine 8379 description even if they have different number of constraints and 8380 modifiers. 8381 8382`m' 8383 A memory operand is allowed, with any kind of address that the 8384 machine supports in general. 8385 8386`o' 8387 A memory operand is allowed, but only if the address is 8388 "offsettable". This means that adding a small integer (actually, 8389 the width in bytes of the operand, as determined by its machine 8390 mode) may be added to the address and the result is also a valid 8391 memory address. 8392 8393 For example, an address which is constant is offsettable; so is an 8394 address that is the sum of a register and a constant (as long as a 8395 slightly larger constant is also within the range of 8396 address-offsets supported by the machine); but an autoincrement or 8397 autodecrement address is not offsettable. More complicated 8398 indirect/indexed addresses may or may not be offsettable depending 8399 on the other addressing modes that the machine supports. 8400 8401 Note that in an output operand which can be matched by another 8402 operand, the constraint letter `o' is valid only when accompanied 8403 by both `<' (if the target machine has predecrement addressing) 8404 and `>' (if the target machine has preincrement addressing). 8405 8406`V' 8407 A memory operand that is not offsettable. In other words, 8408 anything that would fit the `m' constraint but not the `o' 8409 constraint. 8410 8411`<' 8412 A memory operand with autodecrement addressing (either 8413 predecrement or postdecrement) is allowed. 8414 8415`>' 8416 A memory operand with autoincrement addressing (either 8417 preincrement or postincrement) is allowed. 8418 8419`r' 8420 A register operand is allowed provided that it is in a general 8421 register. 8422 8423`i' 8424 An immediate integer operand (one with constant value) is allowed. 8425 This includes symbolic constants whose values will be known only at 8426 assembly time. 8427 8428`n' 8429 An immediate integer operand with a known numeric value is allowed. 8430 Many systems cannot support assembly-time constants for operands 8431 less than a word wide. Constraints for these operands should use 8432 `n' rather than `i'. 8433 8434`I', `J', `K', ... `P' 8435 Other letters in the range `I' through `P' may be defined in a 8436 machine-dependent fashion to permit immediate integer operands with 8437 explicit integer values in specified ranges. For example, on the 8438 68000, `I' is defined to stand for the range of values 1 to 8. 8439 This is the range permitted as a shift count in the shift 8440 instructions. 8441 8442`E' 8443 An immediate floating operand (expression code `const_double') is 8444 allowed, but only if the target floating point format is the same 8445 as that of the host machine (on which the compiler is running). 8446 8447`F' 8448 An immediate floating operand (expression code `const_double' or 8449 `const_vector') is allowed. 8450 8451`G', `H' 8452 `G' and `H' may be defined in a machine-dependent fashion to 8453 permit immediate floating operands in particular ranges of values. 8454 8455`s' 8456 An immediate integer operand whose value is not an explicit 8457 integer is allowed. 8458 8459 This might appear strange; if an insn allows a constant operand 8460 with a value not known at compile time, it certainly must allow 8461 any known value. So why use `s' instead of `i'? Sometimes it 8462 allows better code to be generated. 8463 8464 For example, on the 68000 in a fullword instruction it is possible 8465 to use an immediate operand; but if the immediate value is between 8466 -128 and 127, better code results from loading the value into a 8467 register and using the register. This is because the load into 8468 the register can be done with a `moveq' instruction. We arrange 8469 for this to happen by defining the letter `K' to mean "any integer 8470 outside the range -128 to 127", and then specifying `Ks' in the 8471 operand constraints. 8472 8473`g' 8474 Any register, memory or immediate integer operand is allowed, 8475 except for registers that are not general registers. 8476 8477`X' 8478 Any operand whatsoever is allowed, even if it does not satisfy 8479 `general_operand'. This is normally used in the constraint of a 8480 `match_scratch' when certain alternatives will not actually 8481 require a scratch register. 8482 8483`0', `1', `2', ... `9' 8484 An operand that matches the specified operand number is allowed. 8485 If a digit is used together with letters within the same 8486 alternative, the digit should come last. 8487 8488 This number is allowed to be more than a single digit. If multiple 8489 digits are encountered consecutively, they are interpreted as a 8490 single decimal integer. There is scant chance for ambiguity, 8491 since to-date it has never been desirable that `10' be interpreted 8492 as matching either operand 1 _or_ operand 0. Should this be 8493 desired, one can use multiple alternatives instead. 8494 8495 This is called a "matching constraint" and what it really means is 8496 that the assembler has only a single operand that fills two roles 8497 considered separate in the RTL insn. For example, an add insn has 8498 two input operands and one output operand in the RTL, but on most 8499 CISC machines an add instruction really has only two operands, one 8500 of them an input-output operand: 8501 8502 addl #35,r12 8503 8504 Matching constraints are used in these circumstances. More 8505 precisely, the two operands that match must include one input-only 8506 operand and one output-only operand. Moreover, the digit must be a 8507 smaller number than the number of the operand that uses it in the 8508 constraint. 8509 8510 For operands to match in a particular case usually means that they 8511 are identical-looking RTL expressions. But in a few special cases 8512 specific kinds of dissimilarity are allowed. For example, `*x' as 8513 an input operand will match `*x++' as an output operand. For 8514 proper results in such cases, the output template should always 8515 use the output-operand's number when printing the operand. 8516 8517`p' 8518 An operand that is a valid memory address is allowed. This is for 8519 "load address" and "push address" instructions. 8520 8521 `p' in the constraint must be accompanied by `address_operand' as 8522 the predicate in the `match_operand'. This predicate interprets 8523 the mode specified in the `match_operand' as the mode of the memory 8524 reference for which the address would be valid. 8525 8526OTHER-LETTERS 8527 Other letters can be defined in machine-dependent fashion to stand 8528 for particular classes of registers or other arbitrary operand 8529 types. `d', `a' and `f' are defined on the 68000/68020 to stand 8530 for data, address and floating point registers. 8531 8532 The machine description macro `REG_CLASS_FROM_LETTER' has first 8533 cut at the otherwise unused letters. If it evaluates to `NO_REGS', 8534 then `EXTRA_CONSTRAINT' is evaluated. 8535 8536 A typical use for `EXTRA_CONSTRAINT' would be to distinguish 8537 certain types of memory references that affect other insn operands. 8538 8539 In order to have valid assembler code, each operand must satisfy its 8540constraint. But a failure to do so does not prevent the pattern from 8541applying to an insn. Instead, it directs the compiler to modify the 8542code so that the constraint will be satisfied. Usually this is done by 8543copying an operand into a register. 8544 8545 Contrast, therefore, the two instruction patterns that follow: 8546 8547 (define_insn "" 8548 [(set (match_operand:SI 0 "general_operand" "=r") 8549 (plus:SI (match_dup 0) 8550 (match_operand:SI 1 "general_operand" "r")))] 8551 "" 8552 "...") 8553 8554which has two operands, one of which must appear in two places, and 8555 8556 (define_insn "" 8557 [(set (match_operand:SI 0 "general_operand" "=r") 8558 (plus:SI (match_operand:SI 1 "general_operand" "0") 8559 (match_operand:SI 2 "general_operand" "r")))] 8560 "" 8561 "...") 8562 8563which has three operands, two of which are required by a constraint to 8564be identical. If we are considering an insn of the form 8565 8566 (insn N PREV NEXT 8567 (set (reg:SI 3) 8568 (plus:SI (reg:SI 6) (reg:SI 109))) 8569 ...) 8570 8571the first pattern would not apply at all, because this insn does not 8572contain two identical subexpressions in the right place. The pattern 8573would say, "That does not look like an add instruction; try other 8574patterns." The second pattern would say, "Yes, that's an add 8575instruction, but there is something wrong with it." It would direct 8576the reload pass of the compiler to generate additional insns to make 8577the constraint true. The results might look like this: 8578 8579 (insn N2 PREV N 8580 (set (reg:SI 3) (reg:SI 6)) 8581 ...) 8582 8583 (insn N N2 NEXT 8584 (set (reg:SI 3) 8585 (plus:SI (reg:SI 3) (reg:SI 109))) 8586 ...) 8587 8588 It is up to you to make sure that each operand, in each pattern, has 8589constraints that can handle any RTL expression that could be present for 8590that operand. (When multiple alternatives are in use, each pattern 8591must, for each possible combination of operand expressions, have at 8592least one alternative which can handle that combination of operands.) 8593The constraints don't need to _allow_ any possible operand--when this is 8594the case, they do not constrain--but they must at least point the way to 8595reloading any possible operand so that it will fit. 8596 8597 * If the constraint accepts whatever operands the predicate permits, 8598 there is no problem: reloading is never necessary for this operand. 8599 8600 For example, an operand whose constraints permit everything except 8601 registers is safe provided its predicate rejects registers. 8602 8603 An operand whose predicate accepts only constant values is safe 8604 provided its constraints include the letter `i'. If any possible 8605 constant value is accepted, then nothing less than `i' will do; if 8606 the predicate is more selective, then the constraints may also be 8607 more selective. 8608 8609 * Any operand expression can be reloaded by copying it into a 8610 register. So if an operand's constraints allow some kind of 8611 register, it is certain to be safe. It need not permit all 8612 classes of registers; the compiler knows how to copy a register 8613 into another register of the proper class in order to make an 8614 instruction valid. 8615 8616 * A nonoffsettable memory reference can be reloaded by copying the 8617 address into a register. So if the constraint uses the letter 8618 `o', all memory references are taken care of. 8619 8620 * A constant operand can be reloaded by allocating space in memory to 8621 hold it as preinitialized data. Then the memory reference can be 8622 used in place of the constant. So if the constraint uses the 8623 letters `o' or `m', constant operands are not a problem. 8624 8625 * If the constraint permits a constant and a pseudo register used in 8626 an insn was not allocated to a hard register and is equivalent to 8627 a constant, the register will be replaced with the constant. If 8628 the predicate does not permit a constant and the insn is 8629 re-recognized for some reason, the compiler will crash. Thus the 8630 predicate must always recognize any objects allowed by the 8631 constraint. 8632 8633 If the operand's predicate can recognize registers, but the 8634constraint does not permit them, it can make the compiler crash. When 8635this operand happens to be a register, the reload pass will be stymied, 8636because it does not know how to copy a register temporarily into memory. 8637 8638 If the predicate accepts a unary operator, the constraint applies to 8639the operand. For example, the MIPS processor at ISA level 3 supports an 8640instruction which adds two registers in `SImode' to produce a `DImode' 8641result, but only if the registers are correctly sign extended. This 8642predicate for the input operands accepts a `sign_extend' of an `SImode' 8643register. Write the constraint to indicate the type of register that 8644is required for the operand of the `sign_extend'. 8645 8646 8647File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 8648 864910.7.2 Multiple Alternative Constraints 8650--------------------------------------- 8651 8652Sometimes a single instruction has multiple alternative sets of possible 8653operands. For example, on the 68000, a logical-or instruction can 8654combine register or an immediate value into memory, or it can combine 8655any kind of operand into a register; but it cannot combine one memory 8656location into another. 8657 8658 These constraints are represented as multiple alternatives. An 8659alternative can be described by a series of letters for each operand. 8660The overall constraint for an operand is made from the letters for this 8661operand from the first alternative, a comma, the letters for this 8662operand from the second alternative, a comma, and so on until the last 8663alternative. Here is how it is done for fullword logical-or on the 866468000: 8665 8666 (define_insn "iorsi3" 8667 [(set (match_operand:SI 0 "general_operand" "=m,d") 8668 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 8669 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 8670 ...) 8671 8672 The first alternative has `m' (memory) for operand 0, `0' for 8673operand 1 (meaning it must match operand 0), and `dKs' for operand 2. 8674The second alternative has `d' (data register) for operand 0, `0' for 8675operand 1, and `dmKs' for operand 2. The `=' and `%' in the 8676constraints apply to all the alternatives; their meaning is explained 8677in the next section (*note Class Preferences::). 8678 8679 If all the operands fit any one alternative, the instruction is 8680valid. Otherwise, for each alternative, the compiler counts how many 8681instructions must be added to copy the operands so that that 8682alternative applies. The alternative requiring the least copying is 8683chosen. If two alternatives need the same amount of copying, the one 8684that comes first is chosen. These choices can be altered with the `?' 8685and `!' characters: 8686 8687`?' 8688 Disparage slightly the alternative that the `?' appears in, as a 8689 choice when no alternative applies exactly. The compiler regards 8690 this alternative as one unit more costly for each `?' that appears 8691 in it. 8692 8693`!' 8694 Disparage severely the alternative that the `!' appears in. This 8695 alternative can still be used if it fits without reloading, but if 8696 reloading is needed, some other alternative will be used. 8697 8698 When an insn pattern has multiple alternatives in its constraints, 8699often the appearance of the assembler code is determined mostly by which 8700alternative was matched. When this is so, the C code for writing the 8701assembler code can use the variable `which_alternative', which is the 8702ordinal number of the alternative that was actually satisfied (0 for 8703the first, 1 for the second alternative, etc.). *Note Output 8704Statement::. 8705 8706 8707File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 8708 870910.7.3 Register Class Preferences 8710--------------------------------- 8711 8712The operand constraints have another function: they enable the compiler 8713to decide which kind of hardware register a pseudo register is best 8714allocated to. The compiler examines the constraints that apply to the 8715insns that use the pseudo register, looking for the machine-dependent 8716letters such as `d' and `a' that specify classes of registers. The 8717pseudo register is put in whichever class gets the most "votes". The 8718constraint letters `g' and `r' also vote: they vote in favor of a 8719general register. The machine description says which registers are 8720considered general. 8721 8722 Of course, on some machines all registers are equivalent, and no 8723register classes are defined. Then none of this complexity is relevant. 8724 8725 8726File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 8727 872810.7.4 Constraint Modifier Characters 8729------------------------------------- 8730 8731Here are constraint modifier characters. 8732 8733`=' 8734 Means that this operand is write-only for this instruction: the 8735 previous value is discarded and replaced by output data. 8736 8737`+' 8738 Means that this operand is both read and written by the 8739 instruction. 8740 8741 When the compiler fixes up the operands to satisfy the constraints, 8742 it needs to know which operands are inputs to the instruction and 8743 which are outputs from it. `=' identifies an output; `+' 8744 identifies an operand that is both input and output; all other 8745 operands are assumed to be input only. 8746 8747 If you specify `=' or `+' in a constraint, you put it in the first 8748 character of the constraint string. 8749 8750`&' 8751 Means (in a particular alternative) that this operand is an 8752 "earlyclobber" operand, which is modified before the instruction is 8753 finished using the input operands. Therefore, this operand may 8754 not lie in a register that is used as an input operand or as part 8755 of any memory address. 8756 8757 `&' applies only to the alternative in which it is written. In 8758 constraints with multiple alternatives, sometimes one alternative 8759 requires `&' while others do not. See, for example, the `movdf' 8760 insn of the 68000. 8761 8762 An input operand can be tied to an earlyclobber operand if its only 8763 use as an input occurs before the early result is written. Adding 8764 alternatives of this form often allows GCC to produce better code 8765 when only some of the inputs can be affected by the earlyclobber. 8766 See, for example, the `mulsi3' insn of the ARM. 8767 8768 `&' does not obviate the need to write `='. 8769 8770`%' 8771 Declares the instruction to be commutative for this operand and the 8772 following operand. This means that the compiler may interchange 8773 the two operands if that is the cheapest way to make all operands 8774 fit the constraints. This is often used in patterns for addition 8775 instructions that really have only two operands: the result must 8776 go in one of the arguments. Here for example, is how the 68000 8777 halfword-add instruction is defined: 8778 8779 (define_insn "addhi3" 8780 [(set (match_operand:HI 0 "general_operand" "=m,r") 8781 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 8782 (match_operand:HI 2 "general_operand" "di,g")))] 8783 ...) 8784 GCC can only handle one commutative pair in an asm; if you use 8785 more, the compiler may fail. 8786 8787`#' 8788 Says that all following characters, up to the next comma, are to be 8789 ignored as a constraint. They are significant only for choosing 8790 register preferences. 8791 8792`*' 8793 Says that the following character should be ignored when choosing 8794 register preferences. `*' has no effect on the meaning of the 8795 constraint as a constraint, and no effect on reloading. 8796 8797 Here is an example: the 68000 has an instruction to sign-extend a 8798 halfword in a data register, and can also sign-extend a value by 8799 copying it into an address register. While either kind of 8800 register is acceptable, the constraints on an address-register 8801 destination are less strict, so it is best if register allocation 8802 makes an address register its goal. Therefore, `*' is used so 8803 that the `d' constraint letter (for data register) is ignored when 8804 computing register preferences. 8805 8806 (define_insn "extendhisi2" 8807 [(set (match_operand:SI 0 "general_operand" "=*d,a") 8808 (sign_extend:SI 8809 (match_operand:HI 1 "general_operand" "0,g")))] 8810 ...) 8811 8812 8813File: gccint.info, Node: Machine Constraints, Prev: Modifiers, Up: Constraints 8814 881510.7.5 Constraints for Particular Machines 8816------------------------------------------ 8817 8818Whenever possible, you should use the general-purpose constraint letters 8819in `asm' arguments, since they will convey meaning more readily to 8820people reading your code. Failing that, use the constraint letters 8821that usually have very similar meanings across architectures. The most 8822commonly used constraints are `m' and `r' (for memory and 8823general-purpose registers respectively; *note Simple Constraints::), and 8824`I', usually the letter indicating the most common immediate-constant 8825format. 8826 8827 For each machine architecture, the `config/MACHINE/MACHINE.h' file 8828defines additional constraints. These constraints are used by the 8829compiler itself for instruction generation, as well as for `asm' 8830statements; therefore, some of the constraints are not particularly 8831interesting for `asm'. The constraints are defined through these 8832macros: 8833 8834`REG_CLASS_FROM_LETTER' 8835 Register class constraints (usually lowercase). 8836 8837`CONST_OK_FOR_LETTER_P' 8838 Immediate constant constraints, for non-floating point constants of 8839 word size or smaller precision (usually uppercase). 8840 8841`CONST_DOUBLE_OK_FOR_LETTER_P' 8842 Immediate constant constraints, for all floating point constants 8843 and for constants of greater than word size precision (usually 8844 uppercase). 8845 8846`EXTRA_CONSTRAINT' 8847 Special cases of registers or memory. This macro is not required, 8848 and is only defined for some machines. 8849 8850 Inspecting these macro definitions in the compiler source for your 8851machine is the best way to be certain you have the right constraints. 8852However, here is a summary of the machine-dependent constraints 8853available on some particular machines. 8854 8855_ARM family--`arm.h'_ 8856 8857 `f' 8858 Floating-point register 8859 8860 `F' 8861 One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, 8862 4.0, 5.0 or 10.0 8863 8864 `G' 8865 Floating-point constant that would satisfy the constraint `F' 8866 if it were negated 8867 8868 `I' 8869 Integer that is valid as an immediate operand in a data 8870 processing instruction. That is, an integer in the range 0 8871 to 255 rotated by a multiple of 2 8872 8873 `J' 8874 Integer in the range -4095 to 4095 8875 8876 `K' 8877 Integer that satisfies constraint `I' when inverted (ones 8878 complement) 8879 8880 `L' 8881 Integer that satisfies constraint `I' when negated (twos 8882 complement) 8883 8884 `M' 8885 Integer in the range 0 to 32 8886 8887 `Q' 8888 A memory reference where the exact address is in a single 8889 register (``m'' is preferable for `asm' statements) 8890 8891 `R' 8892 An item in the constant pool 8893 8894 `S' 8895 A symbol in the text segment of the current file 8896 8897_AVR family--`avr.h'_ 8898 8899 `l' 8900 Registers from r0 to r15 8901 8902 `a' 8903 Registers from r16 to r23 8904 8905 `d' 8906 Registers from r16 to r31 8907 8908 `w' 8909 Registers from r24 to r31. These registers can be used in 8910 `adiw' command 8911 8912 `e' 8913 Pointer register (r26-r31) 8914 8915 `b' 8916 Base pointer register (r28-r31) 8917 8918 `q' 8919 Stack pointer register (SPH:SPL) 8920 8921 `t' 8922 Temporary register r0 8923 8924 `x' 8925 Register pair X (r27:r26) 8926 8927 `y' 8928 Register pair Y (r29:r28) 8929 8930 `z' 8931 Register pair Z (r31:r30) 8932 8933 `I' 8934 Constant greater than -1, less than 64 8935 8936 `J' 8937 Constant greater than -64, less than 1 8938 8939 `K' 8940 Constant integer 2 8941 8942 `L' 8943 Constant integer 0 8944 8945 `M' 8946 Constant that fits in 8 bits 8947 8948 `N' 8949 Constant integer -1 8950 8951 `O' 8952 Constant integer 8, 16, or 24 8953 8954 `P' 8955 Constant integer 1 8956 8957 `G' 8958 A floating point constant 0.0 8959 8960_PowerPC and IBM RS6000--`rs6000.h'_ 8961 8962 `b' 8963 Address base register 8964 8965 `f' 8966 Floating point register 8967 8968 `v' 8969 Vector register 8970 8971 `h' 8972 `MQ', `CTR', or `LINK' register 8973 8974 `q' 8975 `MQ' register 8976 8977 `c' 8978 `CTR' register 8979 8980 `l' 8981 `LINK' register 8982 8983 `x' 8984 `CR' register (condition register) number 0 8985 8986 `y' 8987 `CR' register (condition register) 8988 8989 `z' 8990 `FPMEM' stack memory for FPR-GPR transfers 8991 8992 `I' 8993 Signed 16-bit constant 8994 8995 `J' 8996 Unsigned 16-bit constant shifted left 16 bits (use `L' 8997 instead for `SImode' constants) 8998 8999 `K' 9000 Unsigned 16-bit constant 9001 9002 `L' 9003 Signed 16-bit constant shifted left 16 bits 9004 9005 `M' 9006 Constant larger than 31 9007 9008 `N' 9009 Exact power of 2 9010 9011 `O' 9012 Zero 9013 9014 `P' 9015 Constant whose negation is a signed 16-bit constant 9016 9017 `G' 9018 Floating point constant that can be loaded into a register 9019 with one instruction per word 9020 9021 `Q' 9022 Memory operand that is an offset from a register (`m' is 9023 preferable for `asm' statements) 9024 9025 `R' 9026 AIX TOC entry 9027 9028 `S' 9029 Constant suitable as a 64-bit mask operand 9030 9031 `T' 9032 Constant suitable as a 32-bit mask operand 9033 9034 `U' 9035 System V Release 4 small data area reference 9036 9037_Intel 386--`i386.h'_ 9038 9039 `q' 9040 `a', `b', `c', or `d' register for the i386. For x86-64 it 9041 is equivalent to `r' class. (for 8-bit instructions that do 9042 not use upper halves) 9043 9044 `Q' 9045 `a', `b', `c', or `d' register. (for 8-bit instructions, that 9046 do use upper halves) 9047 9048 `R' 9049 Legacy register--equivalent to `r' class in i386 mode. (for 9050 non-8-bit registers used together with 8-bit upper halves in 9051 a single instruction) 9052 9053 `A' 9054 Specifies the `a' or `d' registers. This is primarily useful 9055 for 64-bit integer values (when in 32-bit mode) intended to 9056 be returned with the `d' register holding the most 9057 significant bits and the `a' register holding the least 9058 significant bits. 9059 9060 `f' 9061 Floating point register 9062 9063 `t' 9064 First (top of stack) floating point register 9065 9066 `u' 9067 Second floating point register 9068 9069 `a' 9070 `a' register 9071 9072 `b' 9073 `b' register 9074 9075 `c' 9076 `c' register 9077 9078 `C' 9079 Specifies constant that can be easily constructed in SSE 9080 register without loading it from memory. 9081 9082 `d' 9083 `d' register 9084 9085 `D' 9086 `di' register 9087 9088 `S' 9089 `si' register 9090 9091 `x' 9092 `xmm' SSE register 9093 9094 `y' 9095 MMX register 9096 9097 `I' 9098 Constant in range 0 to 31 (for 32-bit shifts) 9099 9100 `J' 9101 Constant in range 0 to 63 (for 64-bit shifts) 9102 9103 `K' 9104 `0xff' 9105 9106 `L' 9107 `0xffff' 9108 9109 `M' 9110 0, 1, 2, or 3 (shifts for `lea' instruction) 9111 9112 `N' 9113 Constant in range 0 to 255 (for `out' instruction) 9114 9115 `Z' 9116 Constant in range 0 to `0xffffffff' or symbolic reference 9117 known to fit specified range. (for using immediates in zero 9118 extending 32-bit to 64-bit x86-64 instructions) 9119 9120 `e' 9121 Constant in range -2147483648 to 2147483647 or symbolic 9122 reference known to fit specified range. (for using 9123 immediates in 64-bit x86-64 instructions) 9124 9125 `G' 9126 Standard 80387 floating point constant 9127 9128_Intel 960--`i960.h'_ 9129 9130 `f' 9131 Floating point register (`fp0' to `fp3') 9132 9133 `l' 9134 Local register (`r0' to `r15') 9135 9136 `b' 9137 Global register (`g0' to `g15') 9138 9139 `d' 9140 Any local or global register 9141 9142 `I' 9143 Integers from 0 to 31 9144 9145 `J' 9146 0 9147 9148 `K' 9149 Integers from -31 to 0 9150 9151 `G' 9152 Floating point 0 9153 9154 `H' 9155 Floating point 1 9156 9157_Intel IA-64--`ia64.h'_ 9158 9159 `a' 9160 General register `r0' to `r3' for `addl' instruction 9161 9162 `b' 9163 Branch register 9164 9165 `c' 9166 Predicate register (`c' as in "conditional") 9167 9168 `d' 9169 Application register residing in M-unit 9170 9171 `e' 9172 Application register residing in I-unit 9173 9174 `f' 9175 Floating-point register 9176 9177 `m' 9178 Memory operand. Remember that `m' allows postincrement and 9179 postdecrement which require printing with `%Pn' on IA-64. 9180 Use `S' to disallow postincrement and postdecrement. 9181 9182 `G' 9183 Floating-point constant 0.0 or 1.0 9184 9185 `I' 9186 14-bit signed integer constant 9187 9188 `J' 9189 22-bit signed integer constant 9190 9191 `K' 9192 8-bit signed integer constant for logical instructions 9193 9194 `L' 9195 8-bit adjusted signed integer constant for compare pseudo-ops 9196 9197 `M' 9198 6-bit unsigned integer constant for shift counts 9199 9200 `N' 9201 9-bit signed integer constant for load and store 9202 postincrements 9203 9204 `O' 9205 The constant zero 9206 9207 `P' 9208 0 or -1 for `dep' instruction 9209 9210 `Q' 9211 Non-volatile memory for floating-point loads and stores 9212 9213 `R' 9214 Integer constant in the range 1 to 4 for `shladd' instruction 9215 9216 `S' 9217 Memory operand except postincrement and postdecrement 9218 9219_FRV--`frv.h'_ 9220 9221 `a' 9222 Register in the class `ACC_REGS' (`acc0' to `acc7'). 9223 9224 `b' 9225 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). 9226 9227 `c' 9228 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' 9229 to `icc3'). 9230 9231 `d' 9232 Register in the class `GPR_REGS' (`gr0' to `gr63'). 9233 9234 `e' 9235 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd 9236 registers are excluded not in the class but through the use 9237 of a machine mode larger than 4 bytes. 9238 9239 `f' 9240 Register in the class `FPR_REGS' (`fr0' to `fr63'). 9241 9242 `h' 9243 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd 9244 registers are excluded not in the class but through the use 9245 of a machine mode larger than 4 bytes. 9246 9247 `l' 9248 Register in the class `LR_REG' (the `lr' register). 9249 9250 `q' 9251 Register in the class `QUAD_REGS' (`gr2' to `gr63'). 9252 Register numbers not divisible by 4 are excluded not in the 9253 class but through the use of a machine mode larger than 8 9254 bytes. 9255 9256 `t' 9257 Register in the class `ICC_REGS' (`icc0' to `icc3'). 9258 9259 `u' 9260 Register in the class `FCC_REGS' (`fcc0' to `fcc3'). 9261 9262 `v' 9263 Register in the class `ICR_REGS' (`cc4' to `cc7'). 9264 9265 `w' 9266 Register in the class `FCR_REGS' (`cc0' to `cc3'). 9267 9268 `x' 9269 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). 9270 Register numbers not divisible by 4 are excluded not in the 9271 class but through the use of a machine mode larger than 8 9272 bytes. 9273 9274 `z' 9275 Register in the class `SPR_REGS' (`lcr' and `lr'). 9276 9277 `A' 9278 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). 9279 9280 `B' 9281 Register in the class `ACCG_REGS' (`accg0' to `accg7'). 9282 9283 `C' 9284 Register in the class `CR_REGS' (`cc0' to `cc7'). 9285 9286 `G' 9287 Floating point constant zero 9288 9289 `I' 9290 6-bit signed integer constant 9291 9292 `J' 9293 10-bit signed integer constant 9294 9295 `L' 9296 16-bit signed integer constant 9297 9298 `M' 9299 16-bit unsigned integer constant 9300 9301 `N' 9302 12-bit signed integer constant that is negative--i.e. in the 9303 range of -2048 to -1 9304 9305 `O' 9306 Constant zero 9307 9308 `P' 9309 12-bit signed integer constant that is greater than 9310 zero--i.e. in the range of 1 to 2047. 9311 9312 9313_IP2K--`ip2k.h'_ 9314 9315 `a' 9316 `DP' or `IP' registers (general address) 9317 9318 `f' 9319 `IP' register 9320 9321 `j' 9322 `IPL' register 9323 9324 `k' 9325 `IPH' register 9326 9327 `b' 9328 `DP' register 9329 9330 `y' 9331 `DPH' register 9332 9333 `z' 9334 `DPL' register 9335 9336 `q' 9337 `SP' register 9338 9339 `c' 9340 `DP' or `SP' registers (offsettable address) 9341 9342 `d' 9343 Non-pointer registers (not `SP', `DP', `IP') 9344 9345 `u' 9346 Non-SP registers (everything except `SP') 9347 9348 `R' 9349 Indirect through `IP' - Avoid this except for `QImode', since 9350 we can't access extra bytes 9351 9352 `S' 9353 Indirect through `SP' or `DP' with short displacement (0..127) 9354 9355 `T' 9356 Data-section immediate value 9357 9358 `I' 9359 Integers from -255 to -1 9360 9361 `J' 9362 Integers from 0 to 7--valid bit number in a register 9363 9364 `K' 9365 Integers from 0 to 127--valid displacement for addressing mode 9366 9367 `L' 9368 Integers from 1 to 127 9369 9370 `M' 9371 Integer -1 9372 9373 `N' 9374 Integer 1 9375 9376 `O' 9377 Zero 9378 9379 `P' 9380 Integers from 0 to 255 9381 9382_MIPS--`mips.h'_ 9383 9384 `d' 9385 General-purpose integer register 9386 9387 `f' 9388 Floating-point register (if available) 9389 9390 `h' 9391 `Hi' register 9392 9393 `l' 9394 `Lo' register 9395 9396 `x' 9397 `Hi' or `Lo' register 9398 9399 `y' 9400 General-purpose integer register 9401 9402 `z' 9403 Floating-point status register 9404 9405 `I' 9406 Signed 16-bit constant (for arithmetic instructions) 9407 9408 `J' 9409 Zero 9410 9411 `K' 9412 Zero-extended 16-bit constant (for logic instructions) 9413 9414 `L' 9415 Constant with low 16 bits zero (can be loaded with `lui') 9416 9417 `M' 9418 32-bit constant which requires two instructions to load (a 9419 constant which is not `I', `K', or `L') 9420 9421 `N' 9422 Negative 16-bit constant 9423 9424 `O' 9425 Exact power of two 9426 9427 `P' 9428 Positive 16-bit constant 9429 9430 `G' 9431 Floating point zero 9432 9433 `Q' 9434 Memory reference that can be loaded with more than one 9435 instruction (`m' is preferable for `asm' statements) 9436 9437 `R' 9438 Memory reference that can be loaded with one instruction (`m' 9439 is preferable for `asm' statements) 9440 9441 `S' 9442 Memory reference in external OSF/rose PIC format (`m' is 9443 preferable for `asm' statements) 9444 9445_Motorola 680x0--`m68k.h'_ 9446 9447 `a' 9448 Address register 9449 9450 `d' 9451 Data register 9452 9453 `f' 9454 68881 floating-point register, if available 9455 9456 `I' 9457 Integer in the range 1 to 8 9458 9459 `J' 9460 16-bit signed number 9461 9462 `K' 9463 Signed number whose magnitude is greater than 0x80 9464 9465 `L' 9466 Integer in the range -8 to -1 9467 9468 `M' 9469 Signed number whose magnitude is greater than 0x100 9470 9471 `G' 9472 Floating point constant that is not a 68881 constant 9473 9474_Motorola 68HC11 & 68HC12 families--`m68hc11.h'_ 9475 9476 `a' 9477 Register 'a' 9478 9479 `b' 9480 Register 'b' 9481 9482 `d' 9483 Register 'd' 9484 9485 `q' 9486 An 8-bit register 9487 9488 `t' 9489 Temporary soft register _.tmp 9490 9491 `u' 9492 A soft register _.d1 to _.d31 9493 9494 `w' 9495 Stack pointer register 9496 9497 `x' 9498 Register 'x' 9499 9500 `y' 9501 Register 'y' 9502 9503 `z' 9504 Pseudo register 'z' (replaced by 'x' or 'y' at the end) 9505 9506 `A' 9507 An address register: x, y or z 9508 9509 `B' 9510 An address register: x or y 9511 9512 `D' 9513 Register pair (x:d) to form a 32-bit value 9514 9515 `L' 9516 Constants in the range -65536 to 65535 9517 9518 `M' 9519 Constants whose 16-bit low part is zero 9520 9521 `N' 9522 Constant integer 1 or -1 9523 9524 `O' 9525 Constant integer 16 9526 9527 `P' 9528 Constants in the range -8 to 2 9529 9530 9531_SPARC--`sparc.h'_ 9532 9533 `f' 9534 Floating-point register on the SPARC-V8 architecture and 9535 lower floating-point register on the SPARC-V9 architecture. 9536 9537 `e' 9538 Floating-point register. It is equivalent to `f' on the 9539 SPARC-V8 architecture and contains both lower and upper 9540 floating-point registers on the SPARC-V9 architecture. 9541 9542 `c' 9543 Floating-point condition code register. 9544 9545 `d' 9546 Lower floating-point register. It is only valid on the 9547 SPARC-V9 architecture when the Visual Instruction Set is 9548 available. 9549 9550 `b' 9551 Floating-point register. It is only valid on the SPARC-V9 9552 architecture when the Visual Instruction Set is available. 9553 9554 `h' 9555 64-bit global or out register for the SPARC-V8+ architecture. 9556 9557 `I' 9558 Signed 13-bit constant 9559 9560 `J' 9561 Zero 9562 9563 `K' 9564 32-bit constant with the low 12 bits clear (a constant that 9565 can be loaded with the `sethi' instruction) 9566 9567 `L' 9568 A constant in the range supported by `movcc' instructions 9569 9570 `M' 9571 A constant in the range supported by `movrcc' instructions 9572 9573 `N' 9574 Same as `K', except that it verifies that bits that are not 9575 in the lower 32-bit range are all zero. Must be used instead 9576 of `K' for modes wider than `SImode' 9577 9578 `O' 9579 The constant 4096 9580 9581 `G' 9582 Floating-point zero 9583 9584 `H' 9585 Signed 13-bit constant, sign-extended to 32 or 64 bits 9586 9587 `Q' 9588 Floating-point constant whose integral representation can be 9589 moved into an integer register using a single sethi 9590 instruction 9591 9592 `R' 9593 Floating-point constant whose integral representation can be 9594 moved into an integer register using a single mov instruction 9595 9596 `S' 9597 Floating-point constant whose integral representation can be 9598 moved into an integer register using a high/lo_sum 9599 instruction sequence 9600 9601 `T' 9602 Memory address aligned to an 8-byte boundary 9603 9604 `U' 9605 Even register 9606 9607 `W' 9608 Memory address for `e' constraint registers. 9609 9610 9611_TMS320C3x/C4x--`c4x.h'_ 9612 9613 `a' 9614 Auxiliary (address) register (ar0-ar7) 9615 9616 `b' 9617 Stack pointer register (sp) 9618 9619 `c' 9620 Standard (32-bit) precision integer register 9621 9622 `f' 9623 Extended (40-bit) precision register (r0-r11) 9624 9625 `k' 9626 Block count register (bk) 9627 9628 `q' 9629 Extended (40-bit) precision low register (r0-r7) 9630 9631 `t' 9632 Extended (40-bit) precision register (r0-r1) 9633 9634 `u' 9635 Extended (40-bit) precision register (r2-r3) 9636 9637 `v' 9638 Repeat count register (rc) 9639 9640 `x' 9641 Index register (ir0-ir1) 9642 9643 `y' 9644 Status (condition code) register (st) 9645 9646 `z' 9647 Data page register (dp) 9648 9649 `G' 9650 Floating-point zero 9651 9652 `H' 9653 Immediate 16-bit floating-point constant 9654 9655 `I' 9656 Signed 16-bit constant 9657 9658 `J' 9659 Signed 8-bit constant 9660 9661 `K' 9662 Signed 5-bit constant 9663 9664 `L' 9665 Unsigned 16-bit constant 9666 9667 `M' 9668 Unsigned 8-bit constant 9669 9670 `N' 9671 Ones complement of unsigned 16-bit constant 9672 9673 `O' 9674 High 16-bit constant (32-bit constant with 16 LSBs zero) 9675 9676 `Q' 9677 Indirect memory reference with signed 8-bit or index register 9678 displacement 9679 9680 `R' 9681 Indirect memory reference with unsigned 5-bit displacement 9682 9683 `S' 9684 Indirect memory reference with 1 bit or index register 9685 displacement 9686 9687 `T' 9688 Direct memory reference 9689 9690 `U' 9691 Symbolic address 9692 9693 9694_S/390 and zSeries--`s390.h'_ 9695 9696 `a' 9697 Address register (general purpose register except r0) 9698 9699 `d' 9700 Data register (arbitrary general purpose register) 9701 9702 `f' 9703 Floating-point register 9704 9705 `I' 9706 Unsigned 8-bit constant (0-255) 9707 9708 `J' 9709 Unsigned 12-bit constant (0-4095) 9710 9711 `K' 9712 Signed 16-bit constant (-32768-32767) 9713 9714 `L' 9715 Value appropriate as displacement. 9716 `(0..4095)' 9717 for short displacement 9718 9719 `(-524288..524287)' 9720 for long displacement 9721 9722 `M' 9723 Constant integer with a value of 0x7fffffff. 9724 9725 `N' 9726 Multiple letter constraint followed by 4 parameter letters. 9727 `0..9:' 9728 number of the part counting from most to least 9729 significant 9730 9731 `H,Q:' 9732 mode of the part 9733 9734 `D,S,H:' 9735 mode of the containing operand 9736 9737 `0,F:' 9738 value of the other parts (F - all bits set) 9739 The constraint matches if the specified part of a constant 9740 has a value different from it's other parts. 9741 9742 `Q' 9743 Memory reference without index register and with short 9744 displacement. 9745 9746 `R' 9747 Memory reference with index register and short displacement. 9748 9749 `S' 9750 Memory reference without index register but with long 9751 displacement. 9752 9753 `T' 9754 Memory reference with index register and long displacement. 9755 9756 `U' 9757 Pointer with short displacement. 9758 9759 `W' 9760 Pointer with long displacement. 9761 9762 `Y' 9763 Shift count operand. 9764 9765 9766_Xstormy16--`stormy16.h'_ 9767 9768 `a' 9769 Register r0. 9770 9771 `b' 9772 Register r1. 9773 9774 `c' 9775 Register r2. 9776 9777 `d' 9778 Register r8. 9779 9780 `e' 9781 Registers r0 through r7. 9782 9783 `t' 9784 Registers r0 and r1. 9785 9786 `y' 9787 The carry register. 9788 9789 `z' 9790 Registers r8 and r9. 9791 9792 `I' 9793 A constant between 0 and 3 inclusive. 9794 9795 `J' 9796 A constant that has exactly one bit set. 9797 9798 `K' 9799 A constant that has exactly one bit clear. 9800 9801 `L' 9802 A constant between 0 and 255 inclusive. 9803 9804 `M' 9805 A constant between -255 and 0 inclusive. 9806 9807 `N' 9808 A constant between -3 and 0 inclusive. 9809 9810 `O' 9811 A constant between 1 and 4 inclusive. 9812 9813 `P' 9814 A constant between -4 and -1 inclusive. 9815 9816 `Q' 9817 A memory reference that is a stack push. 9818 9819 `R' 9820 A memory reference that is a stack pop. 9821 9822 `S' 9823 A memory reference that refers to a constant address of known 9824 value. 9825 9826 `T' 9827 The register indicated by Rx (not implemented yet). 9828 9829 `U' 9830 A constant that is not between 2 and 15 inclusive. 9831 9832 `Z' 9833 The constant 0. 9834 9835 9836_Xtensa--`xtensa.h'_ 9837 9838 `a' 9839 General-purpose 32-bit register 9840 9841 `b' 9842 One-bit boolean register 9843 9844 `A' 9845 MAC16 40-bit accumulator register 9846 9847 `I' 9848 Signed 12-bit integer constant, for use in MOVI instructions 9849 9850 `J' 9851 Signed 8-bit integer constant, for use in ADDI instructions 9852 9853 `K' 9854 Integer constant valid for BccI instructions 9855 9856 `L' 9857 Unsigned constant valid for BccUI instructions 9858 9859 9860 9861 9862File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 9863 986410.8 Standard Pattern Names For Generation 9865========================================== 9866 9867Here is a table of the instruction names that are meaningful in the RTL 9868generation pass of the compiler. Giving one of these names to an 9869instruction pattern tells the RTL generation pass that it can use the 9870pattern to accomplish a certain task. 9871 9872`movM' 9873 Here M stands for a two-letter machine mode name, in lowercase. 9874 This instruction pattern moves data with that machine mode from 9875 operand 1 to operand 0. For example, `movsi' moves full-word data. 9876 9877 If operand 0 is a `subreg' with mode M of a register whose own 9878 mode is wider than M, the effect of this instruction is to store 9879 the specified value in the part of the register that corresponds 9880 to mode M. Bits outside of M, but which are within the same 9881 target word as the `subreg' are undefined. Bits which are outside 9882 the target word are left unchanged. 9883 9884 This class of patterns is special in several ways. First of all, 9885 each of these names up to and including full word size _must_ be 9886 defined, because there is no other way to copy a datum from one 9887 place to another. If there are patterns accepting operands in 9888 larger modes, `movM' must be defined for integer modes of those 9889 sizes. 9890 9891 Second, these patterns are not used solely in the RTL generation 9892 pass. Even the reload pass can generate move insns to copy values 9893 from stack slots into temporary registers. When it does so, one 9894 of the operands is a hard register and the other is an operand 9895 that can need to be reloaded into a register. 9896 9897 Therefore, when given such a pair of operands, the pattern must 9898 generate RTL which needs no reloading and needs no temporary 9899 registers--no registers other than the operands. For example, if 9900 you support the pattern with a `define_expand', then in such a 9901 case the `define_expand' mustn't call `force_reg' or any other such 9902 function which might generate new pseudo registers. 9903 9904 This requirement exists even for subword modes on a RISC machine 9905 where fetching those modes from memory normally requires several 9906 insns and some temporary registers. 9907 9908 During reload a memory reference with an invalid address may be 9909 passed as an operand. Such an address will be replaced with a 9910 valid address later in the reload pass. In this case, nothing may 9911 be done with the address except to use it as it stands. If it is 9912 copied, it will not be replaced with a valid address. No attempt 9913 should be made to make such an address into a valid address and no 9914 routine (such as `change_address') that will do so may be called. 9915 Note that `general_operand' will fail when applied to such an 9916 address. 9917 9918 The global variable `reload_in_progress' (which must be explicitly 9919 declared if required) can be used to determine whether such special 9920 handling is required. 9921 9922 The variety of operands that have reloads depends on the rest of 9923 the machine description, but typically on a RISC machine these can 9924 only be pseudo registers that did not get hard registers, while on 9925 other machines explicit memory references will get optional 9926 reloads. 9927 9928 If a scratch register is required to move an object to or from 9929 memory, it can be allocated using `gen_reg_rtx' prior to life 9930 analysis. 9931 9932 If there are cases which need scratch registers during or after 9933 reload, you must define `SECONDARY_INPUT_RELOAD_CLASS' and/or 9934 `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide 9935 patterns `reload_inM' or `reload_outM' to handle them. *Note 9936 Register Classes::. 9937 9938 The global variable `no_new_pseudos' can be used to determine if it 9939 is unsafe to create new pseudo registers. If this variable is 9940 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new 9941 pseudo. 9942 9943 The constraints on a `movM' must permit moving any hard register 9944 to any other hard register provided that `HARD_REGNO_MODE_OK' 9945 permits mode M in both registers and `REGISTER_MOVE_COST' applied 9946 to their classes returns a value of 2. 9947 9948 It is obligatory to support floating point `movM' instructions 9949 into and out of any registers that can hold fixed point values, 9950 because unions and structures (which have modes `SImode' or 9951 `DImode') can be in those registers and they may have floating 9952 point members. 9953 9954 There may also be a need to support fixed point `movM' 9955 instructions in and out of floating point registers. 9956 Unfortunately, I have forgotten why this was so, and I don't know 9957 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed 9958 point values in floating point registers, then the constraints of 9959 the fixed point `movM' instructions must be designed to avoid ever 9960 trying to reload into a floating point register. 9961 9962`reload_inM' 9963`reload_outM' 9964 Like `movM', but used when a scratch register is required to move 9965 between operand 0 and operand 1. Operand 2 describes the scratch 9966 register. See the discussion of the `SECONDARY_RELOAD_CLASS' 9967 macro in *note Register Classes::. 9968 9969 There are special restrictions on the form of the `match_operand's 9970 used in these patterns. First, only the predicate for the reload 9971 operand is examined, i.e., `reload_in' examines operand 1, but not 9972 the predicates for operand 0 or 2. Second, there may be only one 9973 alternative in the constraints. Third, only a single register 9974 class letter may be used for the constraint; subsequent constraint 9975 letters are ignored. As a special exception, an empty constraint 9976 string matches the `ALL_REGS' register class. This may relieve 9977 ports of the burden of defining an `ALL_REGS' constraint letter 9978 just for these patterns. 9979 9980`movstrictM' 9981 Like `movM' except that if operand 0 is a `subreg' with mode M of 9982 a register whose natural mode is wider, the `movstrictM' 9983 instruction is guaranteed not to alter any of the register except 9984 the part which belongs to mode M. 9985 9986`load_multiple' 9987 Load several consecutive memory locations into consecutive 9988 registers. Operand 0 is the first of the consecutive registers, 9989 operand 1 is the first memory location, and operand 2 is a 9990 constant: the number of consecutive registers. 9991 9992 Define this only if the target machine really has such an 9993 instruction; do not define this if the most efficient way of 9994 loading consecutive registers from memory is to do them one at a 9995 time. 9996 9997 On some machines, there are restrictions as to which consecutive 9998 registers can be stored into memory, such as particular starting or 9999 ending register numbers or only a range of valid counts. For those 10000 machines, use a `define_expand' (*note Expander Definitions::) and 10001 make the pattern fail if the restrictions are not met. 10002 10003 Write the generated insn as a `parallel' with elements being a 10004 `set' of one register from the appropriate memory location (you may 10005 also need `use' or `clobber' elements). Use a `match_parallel' 10006 (*note RTL Template::) to recognize the insn. See `rs6000.md' for 10007 examples of the use of this insn pattern. 10008 10009`store_multiple' 10010 Similar to `load_multiple', but store several consecutive registers 10011 into consecutive memory locations. Operand 0 is the first of the 10012 consecutive memory locations, operand 1 is the first register, and 10013 operand 2 is a constant: the number of consecutive registers. 10014 10015`pushM' 10016 Output a push instruction. Operand 0 is value to push. Used only 10017 when `PUSH_ROUNDING' is defined. For historical reason, this 10018 pattern may be missing and in such case an `mov' expander is used 10019 instead, with a `MEM' expression forming the push operation. The 10020 `mov' expander method is deprecated. 10021 10022`addM3' 10023 Add operand 2 and operand 1, storing the result in operand 0. All 10024 operands must have mode M. This can be used even on two-address 10025 machines, by means of constraints requiring operands 1 and 0 to be 10026 the same location. 10027 10028`subM3', `mulM3' 10029`divM3', `udivM3', `modM3', `umodM3' 10030`sminM3', `smaxM3', `uminM3', `umaxM3' 10031`andM3', `iorM3', `xorM3' 10032 Similar, for other arithmetic operations. 10033 10034`minM3', `maxM3' 10035 Floating point min and max operations. If both operands are zeros, 10036 or if either operand is NaN, then it is unspecified which of the 10037 two operands is returned as the result. 10038 10039`mulhisi3' 10040 Multiply operands 1 and 2, which have mode `HImode', and store a 10041 `SImode' product in operand 0. 10042 10043`mulqihi3', `mulsidi3' 10044 Similar widening-multiplication instructions of other widths. 10045 10046`umulqihi3', `umulhisi3', `umulsidi3' 10047 Similar widening-multiplication instructions that do unsigned 10048 multiplication. 10049 10050`smulM3_highpart' 10051 Perform a signed multiplication of operands 1 and 2, which have 10052 mode M, and store the most significant half of the product in 10053 operand 0. The least significant half of the product is discarded. 10054 10055`umulM3_highpart' 10056 Similar, but the multiplication is unsigned. 10057 10058`divmodM4' 10059 Signed division that produces both a quotient and a remainder. 10060 Operand 1 is divided by operand 2 to produce a quotient stored in 10061 operand 0 and a remainder stored in operand 3. 10062 10063 For machines with an instruction that produces both a quotient and 10064 a remainder, provide a pattern for `divmodM4' but do not provide 10065 patterns for `divM3' and `modM3'. This allows optimization in the 10066 relatively common case when both the quotient and remainder are 10067 computed. 10068 10069 If an instruction that just produces a quotient or just a remainder 10070 exists and is more efficient than the instruction that produces 10071 both, write the output routine of `divmodM4' to call 10072 `find_reg_note' and look for a `REG_UNUSED' note on the quotient 10073 or remainder and generate the appropriate instruction. 10074 10075`udivmodM4' 10076 Similar, but does unsigned division. 10077 10078`ashlM3' 10079 Arithmetic-shift operand 1 left by a number of bits specified by 10080 operand 2, and store the result in operand 0. Here M is the mode 10081 of operand 0 and operand 1; operand 2's mode is specified by the 10082 instruction pattern, and the compiler will convert the operand to 10083 that mode before generating the instruction. 10084 10085`ashrM3', `lshrM3', `rotlM3', `rotrM3' 10086 Other shift and rotate instructions, analogous to the `ashlM3' 10087 instructions. 10088 10089`negM2' 10090 Negate operand 1 and store the result in operand 0. 10091 10092`absM2' 10093 Store the absolute value of operand 1 into operand 0. 10094 10095`sqrtM2' 10096 Store the square root of operand 1 into operand 0. 10097 10098 The `sqrt' built-in function of C always uses the mode which 10099 corresponds to the C data type `double' and the `sqrtf' built-in 10100 function uses the mode which corresponds to the C data type 10101 `float'. 10102 10103`cosM2' 10104 Store the cosine of operand 1 into operand 0. 10105 10106 The `cos' built-in function of C always uses the mode which 10107 corresponds to the C data type `double' and the `cosf' built-in 10108 function uses the mode which corresponds to the C data type 10109 `float'. 10110 10111`sinM2' 10112 Store the sine of operand 1 into operand 0. 10113 10114 The `sin' built-in function of C always uses the mode which 10115 corresponds to the C data type `double' and the `sinf' built-in 10116 function uses the mode which corresponds to the C data type 10117 `float'. 10118 10119`expM2' 10120 Store the exponential of operand 1 into operand 0. 10121 10122 The `exp' built-in function of C always uses the mode which 10123 corresponds to the C data type `double' and the `expf' built-in 10124 function uses the mode which corresponds to the C data type 10125 `float'. 10126 10127`logM2' 10128 Store the natural logarithm of operand 1 into operand 0. 10129 10130 The `log' built-in function of C always uses the mode which 10131 corresponds to the C data type `double' and the `logf' built-in 10132 function uses the mode which corresponds to the C data type 10133 `float'. 10134 10135`powM3' 10136 Store the value of operand 1 raised to the exponent operand 2 into 10137 operand 0. 10138 10139 The `pow' built-in function of C always uses the mode which 10140 corresponds to the C data type `double' and the `powf' built-in 10141 function uses the mode which corresponds to the C data type 10142 `float'. 10143 10144`atan2M3' 10145 Store the arc tangent (inverse tangent) of operand 1 divided by 10146 operand 2 into operand 0, using the signs of both arguments to 10147 determine the quadrant of the result. 10148 10149 The `atan2' built-in function of C always uses the mode which 10150 corresponds to the C data type `double' and the `atan2f' built-in 10151 function uses the mode which corresponds to the C data type 10152 `float'. 10153 10154`floorM2' 10155 Store the largest integral value not greater than argument. 10156 10157 The `floor' built-in function of C always uses the mode which 10158 corresponds to the C data type `double' and the `floorf' built-in 10159 function uses the mode which corresponds to the C data type 10160 `float'. 10161 10162`truncM2' 10163 Store the argument rounded to integer towards zero. 10164 10165 The `trunc' built-in function of C always uses the mode which 10166 corresponds to the C data type `double' and the `truncf' built-in 10167 function uses the mode which corresponds to the C data type 10168 `float'. 10169 10170`roundM2' 10171 Store the argument rounded to integer away from zero. 10172 10173 The `round' built-in function of C always uses the mode which 10174 corresponds to the C data type `double' and the `roundf' built-in 10175 function uses the mode which corresponds to the C data type 10176 `float'. 10177 10178`ceilM2' 10179 Store the argument rounded to integer away from zero. 10180 10181 The `ceil' built-in function of C always uses the mode which 10182 corresponds to the C data type `double' and the `ceilf' built-in 10183 function uses the mode which corresponds to the C data type 10184 `float'. 10185 10186`nearbyintM2' 10187 Store the argument rounded according to the default rounding mode 10188 10189 The `nearbyint' built-in function of C always uses the mode which 10190 corresponds to the C data type `double' and the `nearbyintf' 10191 built-in function uses the mode which corresponds to the C data 10192 type `float'. 10193 10194`ffsM2' 10195 Store into operand 0 one plus the index of the least significant 10196 1-bit of operand 1. If operand 1 is zero, store zero. M is the 10197 mode of operand 0; operand 1's mode is specified by the instruction 10198 pattern, and the compiler will convert the operand to that mode 10199 before generating the instruction. 10200 10201 The `ffs' built-in function of C always uses the mode which 10202 corresponds to the C data type `int'. 10203 10204`clzM2' 10205 Store into operand 0 the number of leading 0-bits in X, starting 10206 at the most significant bit position. If X is 0, the result is 10207 undefined. M is the mode of operand 0; operand 1's mode is 10208 specified by the instruction pattern, and the compiler will 10209 convert the operand to that mode before generating the instruction. 10210 10211`ctzM2' 10212 Store into operand 0 the number of trailing 0-bits in X, starting 10213 at the least significant bit position. If X is 0, the result is 10214 undefined. M is the mode of operand 0; operand 1's mode is 10215 specified by the instruction pattern, and the compiler will 10216 convert the operand to that mode before generating the instruction. 10217 10218`popcountM2' 10219 Store into operand 0 the number of 1-bits in X. M is the mode of 10220 operand 0; operand 1's mode is specified by the instruction 10221 pattern, and the compiler will convert the operand to that mode 10222 before generating the instruction. 10223 10224`parityM2' 10225 Store into operand 0 the parity of X, i.e. the number of 1-bits in 10226 X modulo 2. M is the mode of operand 0; operand 1's mode is 10227 specified by the instruction pattern, and the compiler will convert 10228 the operand to that mode before generating the instruction. 10229 10230`one_cmplM2' 10231 Store the bitwise-complement of operand 1 into operand 0. 10232 10233`cmpM' 10234 Compare operand 0 and operand 1, and set the condition codes. The 10235 RTL pattern should look like this: 10236 10237 (set (cc0) (compare (match_operand:M 0 ...) 10238 (match_operand:M 1 ...))) 10239 10240`tstM' 10241 Compare operand 0 against zero, and set the condition codes. The 10242 RTL pattern should look like this: 10243 10244 (set (cc0) (match_operand:M 0 ...)) 10245 10246 `tstM' patterns should not be defined for machines that do not use 10247 `(cc0)'. Doing so would confuse the optimizer since it would no 10248 longer be clear which `set' operations were comparisons. The 10249 `cmpM' patterns should be used instead. 10250 10251`movstrM' 10252 Block move instruction. The addresses of the destination and 10253 source strings are the first two operands, and both are in mode 10254 `Pmode'. 10255 10256 The number of bytes to move is the third operand, in mode M. 10257 Usually, you specify `word_mode' for M. However, if you can 10258 generate better code knowing the range of valid lengths is smaller 10259 than those representable in a full word, you should provide a 10260 pattern with a mode corresponding to the range of values you can 10261 handle efficiently (e.g., `QImode' for values in the range 0-127; 10262 note we avoid numbers that appear negative) and also a pattern 10263 with `word_mode'. 10264 10265 The fourth operand is the known shared alignment of the source and 10266 destination, in the form of a `const_int' rtx. Thus, if the 10267 compiler knows that both source and destination are word-aligned, 10268 it may provide the value 4 for this operand. 10269 10270 Descriptions of multiple `movstrM' patterns can only be beneficial 10271 if the patterns for smaller modes have fewer restrictions on their 10272 first, second and fourth operands. Note that the mode M in 10273 `movstrM' does not impose any restriction on the mode of 10274 individually moved data units in the block. 10275 10276 These patterns need not give special consideration to the 10277 possibility that the source and destination strings might overlap. 10278 10279`clrstrM' 10280 Block clear instruction. The addresses of the destination string 10281 is the first operand, in mode `Pmode'. The number of bytes to 10282 clear is the second operand, in mode M. See `movstrM' for a 10283 discussion of the choice of mode. 10284 10285 The third operand is the known alignment of the destination, in 10286 the form of a `const_int' rtx. Thus, if the compiler knows that 10287 the destination is word-aligned, it may provide the value 4 for 10288 this operand. 10289 10290 The use for multiple `clrstrM' is as for `movstrM'. 10291 10292`cmpstrM' 10293 String compare instruction, with five operands. Operand 0 is the 10294 output; it has mode M. The remaining four operands are like the 10295 operands of `movstrM'. The two memory blocks specified are 10296 compared byte by byte in lexicographic order starting at the 10297 beginning of each string. The instruction is not allowed to 10298 prefetch more than one byte at a time since either string may end 10299 in the first byte and reading past that may access an invalid page 10300 or segment and cause a fault. The effect of the instruction is to 10301 store a value in operand 0 whose sign indicates the result of the 10302 comparison. 10303 10304`cmpmemM' 10305 Block compare instruction, with five operands like the operands of 10306 `cmpstrM'. The two memory blocks specified are compared byte by 10307 byte in lexicographic order starting at the beginning of each 10308 block. Unlike `cmpstrM' the instruction can prefetch any bytes in 10309 the two memory blocks. The effect of the instruction is to store 10310 a value in operand 0 whose sign indicates the result of the 10311 comparison. 10312 10313`strlenM' 10314 Compute the length of a string, with three operands. Operand 0 is 10315 the result (of mode M), operand 1 is a `mem' referring to the 10316 first character of the string, operand 2 is the character to 10317 search for (normally zero), and operand 3 is a constant describing 10318 the known alignment of the beginning of the string. 10319 10320`floatMN2' 10321 Convert signed integer operand 1 (valid for fixed point mode M) to 10322 floating point mode N and store in operand 0 (which has mode N). 10323 10324`floatunsMN2' 10325 Convert unsigned integer operand 1 (valid for fixed point mode M) 10326 to floating point mode N and store in operand 0 (which has mode N). 10327 10328`fixMN2' 10329 Convert operand 1 (valid for floating point mode M) to fixed point 10330 mode N as a signed number and store in operand 0 (which has mode 10331 N). This instruction's result is defined only when the value of 10332 operand 1 is an integer. 10333 10334`fixunsMN2' 10335 Convert operand 1 (valid for floating point mode M) to fixed point 10336 mode N as an unsigned number and store in operand 0 (which has 10337 mode N). This instruction's result is defined only when the value 10338 of operand 1 is an integer. 10339 10340`ftruncM2' 10341 Convert operand 1 (valid for floating point mode M) to an integer 10342 value, still represented in floating point mode M, and store it in 10343 operand 0 (valid for floating point mode M). 10344 10345`fix_truncMN2' 10346 Like `fixMN2' but works for any floating point value of mode M by 10347 converting the value to an integer. 10348 10349`fixuns_truncMN2' 10350 Like `fixunsMN2' but works for any floating point value of mode M 10351 by converting the value to an integer. 10352 10353`truncMN2' 10354 Truncate operand 1 (valid for mode M) to mode N and store in 10355 operand 0 (which has mode N). Both modes must be fixed point or 10356 both floating point. 10357 10358`extendMN2' 10359 Sign-extend operand 1 (valid for mode M) to mode N and store in 10360 operand 0 (which has mode N). Both modes must be fixed point or 10361 both floating point. 10362 10363`zero_extendMN2' 10364 Zero-extend operand 1 (valid for mode M) to mode N and store in 10365 operand 0 (which has mode N). Both modes must be fixed point. 10366 10367`extv' 10368 Extract a bit-field from operand 1 (a register or memory operand), 10369 where operand 2 specifies the width in bits and operand 3 the 10370 starting bit, and store it in operand 0. Operand 0 must have mode 10371 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; 10372 often `word_mode' is allowed only for registers. Operands 2 and 3 10373 must be valid for `word_mode'. 10374 10375 The RTL generation pass generates this instruction only with 10376 constants for operands 2 and 3. 10377 10378 The bit-field value is sign-extended to a full word integer before 10379 it is stored in operand 0. 10380 10381`extzv' 10382 Like `extv' except that the bit-field value is zero-extended. 10383 10384`insv' 10385 Store operand 3 (which must be valid for `word_mode') into a 10386 bit-field in operand 0, where operand 1 specifies the width in 10387 bits and operand 2 the starting bit. Operand 0 may have mode 10388 `byte_mode' or `word_mode'; often `word_mode' is allowed only for 10389 registers. Operands 1 and 2 must be valid for `word_mode'. 10390 10391 The RTL generation pass generates this instruction only with 10392 constants for operands 1 and 2. 10393 10394`movMODEcc' 10395 Conditionally move operand 2 or operand 3 into operand 0 according 10396 to the comparison in operand 1. If the comparison is true, 10397 operand 2 is moved into operand 0, otherwise operand 3 is moved. 10398 10399 The mode of the operands being compared need not be the same as 10400 the operands being moved. Some machines, sparc64 for example, 10401 have instructions that conditionally move an integer value based 10402 on the floating point condition codes and vice versa. 10403 10404 If the machine does not have conditional move instructions, do not 10405 define these patterns. 10406 10407`addMODEcc' 10408 Similar to `movMODEcc' but for conditional addition. Conditionally 10409 move operand 2 or (operands 2 + operand 3) into operand 0 10410 according to the comparison in operand 1. If the comparison is 10411 true, operand 2 is moved into operand 0, otherwise (operand 2 + 10412 operand 3) is moved. 10413 10414`sCOND' 10415 Store zero or nonzero in the operand according to the condition 10416 codes. Value stored is nonzero iff the condition COND is true. 10417 COND is the name of a comparison operation expression code, such 10418 as `eq', `lt' or `leu'. 10419 10420 You specify the mode that the operand must have when you write the 10421 `match_operand' expression. The compiler automatically sees which 10422 mode you have used and supplies an operand of that mode. 10423 10424 The value stored for a true condition must have 1 as its low bit, 10425 or else must be negative. Otherwise the instruction is not 10426 suitable and you should omit it from the machine description. You 10427 describe to the compiler exactly which value is stored by defining 10428 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description 10429 cannot be found that can be used for all the `sCOND' patterns, you 10430 should omit those operations from the machine description. 10431 10432 These operations may fail, but should do so only in relatively 10433 uncommon cases; if they would fail for common cases involving 10434 integer comparisons, it is best to omit these patterns. 10435 10436 If these operations are omitted, the compiler will usually 10437 generate code that copies the constant one to the target and 10438 branches around an assignment of zero to the target. If this code 10439 is more efficient than the potential instructions used for the 10440 `sCOND' pattern followed by those required to convert the result 10441 into a 1 or a zero in `SImode', you should omit the `sCOND' 10442 operations from the machine description. 10443 10444`bCOND' 10445 Conditional branch instruction. Operand 0 is a `label_ref' that 10446 refers to the label to jump to. Jump if the condition codes meet 10447 condition COND. 10448 10449 Some machines do not follow the model assumed here where a 10450 comparison instruction is followed by a conditional branch 10451 instruction. In that case, the `cmpM' (and `tstM') patterns should 10452 simply store the operands away and generate all the required insns 10453 in a `define_expand' (*note Expander Definitions::) for the 10454 conditional branch operations. All calls to expand `bCOND' 10455 patterns are immediately preceded by calls to expand either a 10456 `cmpM' pattern or a `tstM' pattern. 10457 10458 Machines that use a pseudo register for the condition code value, 10459 or where the mode used for the comparison depends on the condition 10460 being tested, should also use the above mechanism. *Note Jump 10461 Patterns::. 10462 10463 The above discussion also applies to the `movMODEcc' and `sCOND' 10464 patterns. 10465 10466`jump' 10467 A jump inside a function; an unconditional branch. Operand 0 is 10468 the `label_ref' of the label to jump to. This pattern name is 10469 mandatory on all machines. 10470 10471`call' 10472 Subroutine call instruction returning no value. Operand 0 is the 10473 function to call; operand 1 is the number of bytes of arguments 10474 pushed as a `const_int'; operand 2 is the number of registers used 10475 as operands. 10476 10477 On most machines, operand 2 is not actually stored into the RTL 10478 pattern. It is supplied for the sake of some RISC machines which 10479 need to put this information into the assembler code; they can put 10480 it in the RTL instead of operand 1. 10481 10482 Operand 0 should be a `mem' RTX whose address is the address of the 10483 function. Note, however, that this address can be a `symbol_ref' 10484 expression even if it would not be a legitimate memory address on 10485 the target machine. If it is also not a valid argument for a call 10486 instruction, the pattern for this operation should be a 10487 `define_expand' (*note Expander Definitions::) that places the 10488 address into a register and uses that register in the call 10489 instruction. 10490 10491`call_value' 10492 Subroutine call instruction returning a value. Operand 0 is the 10493 hard register in which the value is returned. There are three more 10494 operands, the same as the three operands of the `call' instruction 10495 (but with numbers increased by one). 10496 10497 Subroutines that return `BLKmode' objects use the `call' insn. 10498 10499`call_pop', `call_value_pop' 10500 Similar to `call' and `call_value', except used if defined and if 10501 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that 10502 contains both the function call and a `set' to indicate the 10503 adjustment made to the frame pointer. 10504 10505 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of 10506 these patterns increases the number of functions for which the 10507 frame pointer can be eliminated, if desired. 10508 10509`untyped_call' 10510 Subroutine call instruction returning a value of any type. 10511 Operand 0 is the function to call; operand 1 is a memory location 10512 where the result of calling the function is to be stored; operand 10513 2 is a `parallel' expression where each element is a `set' 10514 expression that indicates the saving of a function return value 10515 into the result block. 10516 10517 This instruction pattern should be defined to support 10518 `__builtin_apply' on machines where special instructions are needed 10519 to call a subroutine with arbitrary arguments or to save the value 10520 returned. This instruction pattern is required on machines that 10521 have multiple registers that can hold a return value (i.e. 10522 `FUNCTION_VALUE_REGNO_P' is true for more than one register). 10523 10524`return' 10525 Subroutine return instruction. This instruction pattern name 10526 should be defined only if a single instruction can do all the work 10527 of returning from a function. 10528 10529 Like the `movM' patterns, this pattern is also used after the RTL 10530 generation phase. In this case it is to support machines where 10531 multiple instructions are usually needed to return from a 10532 function, but some class of functions only requires one 10533 instruction to implement a return. Normally, the applicable 10534 functions are those which do not need to save any registers or 10535 allocate stack space. 10536 10537 For such machines, the condition specified in this pattern should 10538 only be true when `reload_completed' is nonzero and the function's 10539 epilogue would only be a single instruction. For machines with 10540 register windows, the routine `leaf_function_p' may be used to 10541 determine if a register window push is required. 10542 10543 Machines that have conditional return instructions should define 10544 patterns such as 10545 10546 (define_insn "" 10547 [(set (pc) 10548 (if_then_else (match_operator 10549 0 "comparison_operator" 10550 [(cc0) (const_int 0)]) 10551 (return) 10552 (pc)))] 10553 "CONDITION" 10554 "...") 10555 10556 where CONDITION would normally be the same condition specified on 10557 the named `return' pattern. 10558 10559`untyped_return' 10560 Untyped subroutine return instruction. This instruction pattern 10561 should be defined to support `__builtin_return' on machines where 10562 special instructions are needed to return a value of any type. 10563 10564 Operand 0 is a memory location where the result of calling a 10565 function with `__builtin_apply' is stored; operand 1 is a 10566 `parallel' expression where each element is a `set' expression 10567 that indicates the restoring of a function return value from the 10568 result block. 10569 10570`nop' 10571 No-op instruction. This instruction pattern name should always be 10572 defined to output a no-op in assembler code. `(const_int 0)' will 10573 do as an RTL pattern. 10574 10575`indirect_jump' 10576 An instruction to jump to an address which is operand zero. This 10577 pattern name is mandatory on all machines. 10578 10579`casesi' 10580 Instruction to jump through a dispatch table, including bounds 10581 checking. This instruction takes five operands: 10582 10583 1. The index to dispatch on, which has mode `SImode'. 10584 10585 2. The lower bound for indices in the table, an integer constant. 10586 10587 3. The total range of indices in the table--the largest index 10588 minus the smallest one (both inclusive). 10589 10590 4. A label that precedes the table itself. 10591 10592 5. A label to jump to if the index has a value outside the 10593 bounds. (If the machine-description macro 10594 `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index 10595 drops through to the code following the jump table instead of 10596 jumping to this label. In that case, this label is not 10597 actually used by the `casesi' instruction, but it is always 10598 provided as an operand.) 10599 10600 The table is a `addr_vec' or `addr_diff_vec' inside of a 10601 `jump_insn'. The number of elements in the table is one plus the 10602 difference between the upper bound and the lower bound. 10603 10604`tablejump' 10605 Instruction to jump to a variable address. This is a low-level 10606 capability which can be used to implement a dispatch table when 10607 there is no `casesi' pattern. 10608 10609 This pattern requires two operands: the address or offset, and a 10610 label which should immediately precede the jump table. If the 10611 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 10612 the first operand is an offset which counts from the address of 10613 the table; otherwise, it is an absolute address to jump to. In 10614 either case, the first operand has mode `Pmode'. 10615 10616 The `tablejump' insn is always the last insn before the jump table 10617 it uses. Its assembler code normally has no need to use the 10618 second operand, but you should incorporate it in the RTL pattern so 10619 that the jump optimizer will not delete the table as unreachable 10620 code. 10621 10622`decrement_and_branch_until_zero' 10623 Conditional branch instruction that decrements a register and 10624 jumps if the register is nonzero. Operand 0 is the register to 10625 decrement and test; operand 1 is the label to jump to if the 10626 register is nonzero. *Note Looping Patterns::. 10627 10628 This optional instruction pattern is only used by the combiner, 10629 typically for loops reversed by the loop optimizer when strength 10630 reduction is enabled. 10631 10632`doloop_end' 10633 Conditional branch instruction that decrements a register and 10634 jumps if the register is nonzero. This instruction takes five 10635 operands: Operand 0 is the register to decrement and test; operand 10636 1 is the number of loop iterations as a `const_int' or 10637 `const0_rtx' if this cannot be determined until run-time; operand 10638 2 is the actual or estimated maximum number of iterations as a 10639 `const_int'; operand 3 is the number of enclosed loops as a 10640 `const_int' (an innermost loop has a value of 1); operand 4 is the 10641 label to jump to if the register is nonzero. *Note Looping 10642 Patterns::. 10643 10644 This optional instruction pattern should be defined for machines 10645 with low-overhead looping instructions as the loop optimizer will 10646 try to modify suitable loops to utilize it. If nested 10647 low-overhead looping is not supported, use a `define_expand' 10648 (*note Expander Definitions::) and make the pattern fail if 10649 operand 3 is not `const1_rtx'. Similarly, if the actual or 10650 estimated maximum number of iterations is too large for this 10651 instruction, make it fail. 10652 10653`doloop_begin' 10654 Companion instruction to `doloop_end' required for machines that 10655 need to perform some initialization, such as loading special 10656 registers used by a low-overhead looping instruction. If 10657 initialization insns do not always need to be emitted, use a 10658 `define_expand' (*note Expander Definitions::) and make it fail. 10659 10660`canonicalize_funcptr_for_compare' 10661 Canonicalize the function pointer in operand 1 and store the result 10662 into operand 0. 10663 10664 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be 10665 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode 10666 `Pmode'. 10667 10668 Canonicalization of a function pointer usually involves computing 10669 the address of the function which would be called if the function 10670 pointer were used in an indirect call. 10671 10672 Only define this pattern if function pointers on the target machine 10673 can have different values but still call the same function when 10674 used in an indirect call. 10675 10676`save_stack_block' 10677`save_stack_function' 10678`save_stack_nonlocal' 10679`restore_stack_block' 10680`restore_stack_function' 10681`restore_stack_nonlocal' 10682 Most machines save and restore the stack pointer by copying it to 10683 or from an object of mode `Pmode'. Do not define these patterns on 10684 such machines. 10685 10686 Some machines require special handling for stack pointer saves and 10687 restores. On those machines, define the patterns corresponding to 10688 the non-standard cases by using a `define_expand' (*note Expander 10689 Definitions::) that produces the required insns. The three types 10690 of saves and restores are: 10691 10692 1. `save_stack_block' saves the stack pointer at the start of a 10693 block that allocates a variable-sized object, and 10694 `restore_stack_block' restores the stack pointer when the 10695 block is exited. 10696 10697 2. `save_stack_function' and `restore_stack_function' do a 10698 similar job for the outermost block of a function and are 10699 used when the function allocates variable-sized objects or 10700 calls `alloca'. Only the epilogue uses the restored stack 10701 pointer, allowing a simpler save or restore sequence on some 10702 machines. 10703 10704 3. `save_stack_nonlocal' is used in functions that contain labels 10705 branched to by nested functions. It saves the stack pointer 10706 in such a way that the inner function can use 10707 `restore_stack_nonlocal' to restore the stack pointer. The 10708 compiler generates code to restore the frame and argument 10709 pointer registers, but some machines require saving and 10710 restoring additional data such as register window information 10711 or stack backchains. Place insns in these patterns to save 10712 and restore any such required data. 10713 10714 When saving the stack pointer, operand 0 is the save area and 10715 operand 1 is the stack pointer. The mode used to allocate the 10716 save area defaults to `Pmode' but you can override that choice by 10717 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 10718 You must specify an integral mode, or `VOIDmode' if no save area 10719 is needed for a particular type of save (either because no save is 10720 needed or because a machine-specific save area can be used). 10721 Operand 0 is the stack pointer and operand 1 is the save area for 10722 restore operations. If `save_stack_block' is defined, operand 0 10723 must not be `VOIDmode' since these saves can be arbitrarily nested. 10724 10725 A save area is a `mem' that is at a constant offset from 10726 `virtual_stack_vars_rtx' when the stack pointer is saved for use by 10727 nonlocal gotos and a `reg' in the other two cases. 10728 10729`allocate_stack' 10730 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 10731 from the stack pointer to create space for dynamically allocated 10732 data. 10733 10734 Store the resultant pointer to this space into operand 0. If you 10735 are allocating space from the main stack, do this by emitting a 10736 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If 10737 you are allocating the space elsewhere, generate code to copy the 10738 location of the space to operand 0. In the latter case, you must 10739 ensure this space gets freed when the corresponding space on the 10740 main stack is free. 10741 10742 Do not define this pattern if all that must be done is the 10743 subtraction. Some machines require other operations such as stack 10744 probes or maintaining the back chain. Define this pattern to emit 10745 those operations in addition to updating the stack pointer. 10746 10747`check_stack' 10748 If stack checking cannot be done on your system by probing the 10749 stack with a load or store instruction (*note Stack Checking::), 10750 define this pattern to perform the needed check and signaling an 10751 error if the stack has overflowed. The single operand is the 10752 location in the stack furthest from the current stack pointer that 10753 you need to validate. Normally, on machines where this pattern is 10754 needed, you would obtain the stack limit from a global or 10755 thread-specific variable or register. 10756 10757`nonlocal_goto' 10758 Emit code to generate a non-local goto, e.g., a jump from one 10759 function to a label in an outer function. This pattern has four 10760 arguments, each representing a value to be used in the jump. The 10761 first argument is to be loaded into the frame pointer, the second 10762 is the address to branch to (code to dispatch to the actual label), 10763 the third is the address of a location where the stack is saved, 10764 and the last is the address of the label, to be placed in the 10765 location for the incoming static chain. 10766 10767 On most machines you need not define this pattern, since GCC will 10768 already generate the correct code, which is to load the frame 10769 pointer and static chain, restore the stack (using the 10770 `restore_stack_nonlocal' pattern, if defined), and jump indirectly 10771 to the dispatcher. You need only define this pattern if this code 10772 will not work on your machine. 10773 10774`nonlocal_goto_receiver' 10775 This pattern, if defined, contains code needed at the target of a 10776 nonlocal goto after the code already generated by GCC. You will 10777 not normally need to define this pattern. A typical reason why 10778 you might need this pattern is if some value, such as a pointer to 10779 a global table, must be restored when the frame pointer is 10780 restored. Note that a nonlocal goto only occurs within a 10781 unit-of-translation, so a global table pointer that is shared by 10782 all functions of a given module need not be restored. There are 10783 no arguments. 10784 10785`exception_receiver' 10786 This pattern, if defined, contains code needed at the site of an 10787 exception handler that isn't needed at the site of a nonlocal 10788 goto. You will not normally need to define this pattern. A 10789 typical reason why you might need this pattern is if some value, 10790 such as a pointer to a global table, must be restored after 10791 control flow is branched to the handler of an exception. There 10792 are no arguments. 10793 10794`builtin_setjmp_setup' 10795 This pattern, if defined, contains additional code needed to 10796 initialize the `jmp_buf'. You will not normally need to define 10797 this pattern. A typical reason why you might need this pattern is 10798 if some value, such as a pointer to a global table, must be 10799 restored. Though it is preferred that the pointer value be 10800 recalculated if possible (given the address of a label for 10801 instance). The single argument is a pointer to the `jmp_buf'. 10802 Note that the buffer is five words long and that the first three 10803 are normally used by the generic mechanism. 10804 10805`builtin_setjmp_receiver' 10806 This pattern, if defined, contains code needed at the site of an 10807 built-in setjmp that isn't needed at the site of a nonlocal goto. 10808 You will not normally need to define this pattern. A typical 10809 reason why you might need this pattern is if some value, such as a 10810 pointer to a global table, must be restored. It takes one 10811 argument, which is the label to which builtin_longjmp transfered 10812 control; this pattern may be emitted at a small offset from that 10813 label. 10814 10815`builtin_longjmp' 10816 This pattern, if defined, performs the entire action of the 10817 longjmp. You will not normally need to define this pattern unless 10818 you also define `builtin_setjmp_setup'. The single argument is a 10819 pointer to the `jmp_buf'. 10820 10821`eh_return' 10822 This pattern, if defined, affects the way `__builtin_eh_return', 10823 and thence the call frame exception handling library routines, are 10824 built. It is intended to handle non-trivial actions needed along 10825 the abnormal return path. 10826 10827 The address of the exception handler to which the function should 10828 return is passed as operand to this pattern. It will normally 10829 need to copied by the pattern to some special register or memory 10830 location. If the pattern needs to determine the location of the 10831 target call frame in order to do so, it may use 10832 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been 10833 assigned. 10834 10835 If this pattern is not defined, the default action will be to 10836 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either 10837 that macro or this pattern needs to be defined if call frame 10838 exception handling is to be used. 10839 10840`prologue' 10841 This pattern, if defined, emits RTL for entry to a function. The 10842 function entry is responsible for setting up the stack frame, 10843 initializing the frame pointer register, saving callee saved 10844 registers, etc. 10845 10846 Using a prologue pattern is generally preferred over defining 10847 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 10848 prologue. 10849 10850 The `prologue' pattern is particularly useful for targets which 10851 perform instruction scheduling. 10852 10853`epilogue' 10854 This pattern emits RTL for exit from a function. The function 10855 exit is responsible for deallocating the stack frame, restoring 10856 callee saved registers and emitting the return instruction. 10857 10858 Using an epilogue pattern is generally preferred over defining 10859 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 10860 epilogue. 10861 10862 The `epilogue' pattern is particularly useful for targets which 10863 perform instruction scheduling or which have delay slots for their 10864 return instruction. 10865 10866`sibcall_epilogue' 10867 This pattern, if defined, emits RTL for exit from a function 10868 without the final branch back to the calling function. This 10869 pattern will be emitted before any sibling call (aka tail call) 10870 sites. 10871 10872 The `sibcall_epilogue' pattern must not clobber any arguments used 10873 for parameter passing or any stack slots for arguments passed to 10874 the current function. 10875 10876`trap' 10877 This pattern, if defined, signals an error, typically by causing 10878 some kind of signal to be raised. Among other places, it is used 10879 by the Java front end to signal `invalid array index' exceptions. 10880 10881`conditional_trap' 10882 Conditional trap instruction. Operand 0 is a piece of RTL which 10883 performs a comparison. Operand 1 is the trap code, an integer. 10884 10885 A typical `conditional_trap' pattern looks like 10886 10887 (define_insn "conditional_trap" 10888 [(trap_if (match_operator 0 "trap_operator" 10889 [(cc0) (const_int 0)]) 10890 (match_operand 1 "const_int_operand" "i"))] 10891 "" 10892 "...") 10893 10894`prefetch' 10895 This pattern, if defined, emits code for a non-faulting data 10896 prefetch instruction. Operand 0 is the address of the memory to 10897 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 10898 for a write to the memory address, or a constant 0 otherwise. 10899 Operand 2 is the expected degree of temporal locality of the data 10900 and is a value between 0 and 3, inclusive; 0 means that the data 10901 has no temporal locality, so it need not be left in the cache 10902 after the access; 3 means that the data has a high degree of 10903 temporal locality and should be left in all levels of cache 10904 possible; 1 and 2 mean, respectively, a low or moderate degree of 10905 temporal locality. 10906 10907 Targets that do not support write prefetches or locality hints can 10908 ignore the values of operands 1 and 2. 10909 10910 10911 10912File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 10913 1091410.9 When the Order of Patterns Matters 10915======================================= 10916 10917Sometimes an insn can match more than one instruction pattern. Then the 10918pattern that appears first in the machine description is the one used. 10919Therefore, more specific patterns (patterns that will match fewer 10920things) and faster instructions (those that will produce better code 10921when they do match) should usually go first in the description. 10922 10923 In some cases the effect of ordering the patterns can be used to hide 10924a pattern when it is not valid. For example, the 68000 has an 10925instruction for converting a fullword to floating point and another for 10926converting a byte to floating point. An instruction converting an 10927integer to floating point could match either one. We put the pattern 10928to convert the fullword first to make sure that one will be used rather 10929than the other. (Otherwise a large integer might be generated as a 10930single-byte immediate quantity, which would not work.) Instead of 10931using this pattern ordering it would be possible to make the pattern 10932for convert-a-byte smart enough to deal properly with any constant 10933value. 10934 10935 10936File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 10937 1093810.10 Interdependence of Patterns 10939================================= 10940 10941Every machine description must have a named pattern for each of the 10942conditional branch names `bCOND'. The recognition template must always 10943have the form 10944 10945 (set (pc) 10946 (if_then_else (COND (cc0) (const_int 0)) 10947 (label_ref (match_operand 0 "" "")) 10948 (pc))) 10949 10950In addition, every machine description must have an anonymous pattern 10951for each of the possible reverse-conditional branches. Their templates 10952look like 10953 10954 (set (pc) 10955 (if_then_else (COND (cc0) (const_int 0)) 10956 (pc) 10957 (label_ref (match_operand 0 "" "")))) 10958 10959They are necessary because jump optimization can turn direct-conditional 10960branches into reverse-conditional branches. 10961 10962 It is often convenient to use the `match_operator' construct to 10963reduce the number of patterns that must be specified for branches. For 10964example, 10965 10966 (define_insn "" 10967 [(set (pc) 10968 (if_then_else (match_operator 0 "comparison_operator" 10969 [(cc0) (const_int 0)]) 10970 (pc) 10971 (label_ref (match_operand 1 "" ""))))] 10972 "CONDITION" 10973 "...") 10974 10975 In some cases machines support instructions identical except for the 10976machine mode of one or more operands. For example, there may be 10977"sign-extend halfword" and "sign-extend byte" instructions whose 10978patterns are 10979 10980 (set (match_operand:SI 0 ...) 10981 (extend:SI (match_operand:HI 1 ...))) 10982 10983 (set (match_operand:SI 0 ...) 10984 (extend:SI (match_operand:QI 1 ...))) 10985 10986Constant integers do not specify a machine mode, so an instruction to 10987extend a constant value could match either pattern. The pattern it 10988actually will match is the one that appears first in the file. For 10989correct results, this must be the one for the widest possible mode 10990(`HImode', here). If the pattern matches the `QImode' instruction, the 10991results will be incorrect if the constant value does not actually fit 10992that mode. 10993 10994 Such instructions to extend constants are rarely generated because 10995they are optimized away, but they do occasionally happen in nonoptimized 10996compilations. 10997 10998 If a constraint in a pattern allows a constant, the reload pass may 10999replace a register with a constant permitted by the constraint in some 11000cases. Similarly for memory references. Because of this substitution, 11001you should not provide separate patterns for increment and decrement 11002instructions. Instead, they should be generated from the same pattern 11003that supports register-register add insns by examining the operands and 11004generating the appropriate machine instruction. 11005 11006 11007File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 11008 1100910.11 Defining Jump Instruction Patterns 11010======================================== 11011 11012For most machines, GCC assumes that the machine has a condition code. 11013A comparison insn sets the condition code, recording the results of both 11014signed and unsigned comparison of the given operands. A separate branch 11015insn tests the condition code and branches or not according its value. 11016The branch insns come in distinct signed and unsigned flavors. Many 11017common machines, such as the VAX, the 68000 and the 32000, work this 11018way. 11019 11020 Some machines have distinct signed and unsigned compare 11021instructions, and only one set of conditional branch instructions. The 11022easiest way to handle these machines is to treat them just like the 11023others until the final stage where assembly code is written. At this 11024time, when outputting code for the compare instruction, peek ahead at 11025the following branch using `next_cc0_user (insn)'. (The variable 11026`insn' refers to the insn being output, in the output-writing code in 11027an instruction pattern.) If the RTL says that is an unsigned branch, 11028output an unsigned compare; otherwise output a signed compare. When 11029the branch itself is output, you can treat signed and unsigned branches 11030identically. 11031 11032 The reason you can do this is that GCC always generates a pair of 11033consecutive RTL insns, possibly separated by `note' insns, one to set 11034the condition code and one to test it, and keeps the pair inviolate 11035until the end. 11036 11037 To go with this technique, you must define the machine-description 11038macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no 11039compare instruction is superfluous. 11040 11041 Some machines have compare-and-branch instructions and no condition 11042code. A similar technique works for them. When it is time to "output" 11043a compare instruction, record its operands in two static variables. 11044When outputting the branch-on-condition-code instruction that follows, 11045actually output a compare-and-branch instruction that uses the 11046remembered operands. 11047 11048 It also works to define patterns for compare-and-branch instructions. 11049In optimizing compilation, the pair of compare and branch instructions 11050will be combined according to these patterns. But this does not happen 11051if optimization is not requested. So you must use one of the solutions 11052above in addition to any special patterns you define. 11053 11054 In many RISC machines, most instructions do not affect the condition 11055code and there may not even be a separate condition code register. On 11056these machines, the restriction that the definition and use of the 11057condition code be adjacent insns is not necessary and can prevent 11058important optimizations. For example, on the IBM RS/6000, there is a 11059delay for taken branches unless the condition code register is set three 11060instructions earlier than the conditional branch. The instruction 11061scheduler cannot perform this optimization if it is not permitted to 11062separate the definition and use of the condition code register. 11063 11064 On these machines, do not use `(cc0)', but instead use a register to 11065represent the condition code. If there is a specific condition code 11066register in the machine, use a hard register. If the condition code or 11067comparison result can be placed in any general register, or if there are 11068multiple condition registers, use a pseudo register. 11069 11070 On some machines, the type of branch instruction generated may 11071depend on the way the condition code was produced; for example, on the 1107268k and SPARC, setting the condition code directly from an add or 11073subtract instruction does not clear the overflow bit the way that a test 11074instruction does, so a different branch instruction must be used for 11075some conditional branches. For machines that use `(cc0)', the set and 11076use of the condition code must be adjacent (separated only by `note' 11077insns) allowing flags in `cc_status' to be used. (*Note Condition 11078Code::.) Also, the comparison and branch insns can be located from 11079each other by using the functions `prev_cc0_setter' and `next_cc0_user'. 11080 11081 However, this is not true on machines that do not use `(cc0)'. On 11082those machines, no assumptions can be made about the adjacency of the 11083compare and branch insns and the above methods cannot be used. Instead, 11084we use the machine mode of the condition code register to record 11085different formats of the condition code register. 11086 11087 Registers used to store the condition code value should have a mode 11088that is in class `MODE_CC'. Normally, it will be `CCmode'. If 11089additional modes are required (as for the add example mentioned above in 11090the SPARC), define the macro `EXTRA_CC_MODES' to list the additional 11091modes required (*note Condition Code::). Also define `SELECT_CC_MODE' 11092to choose a mode given an operand of a compare. 11093 11094 If it is known during RTL generation that a different mode will be 11095required (for example, if the machine has separate compare instructions 11096for signed and unsigned quantities, like most IBM processors), they can 11097be specified at that time. 11098 11099 If the cases that require different modes would be made by 11100instruction combination, the macro `SELECT_CC_MODE' determines which 11101machine mode should be used for the comparison result. The patterns 11102should be written using that mode. To support the case of the add on 11103the SPARC discussed above, we have the pattern 11104 11105 (define_insn "" 11106 [(set (reg:CC_NOOV 0) 11107 (compare:CC_NOOV 11108 (plus:SI (match_operand:SI 0 "register_operand" "%r") 11109 (match_operand:SI 1 "arith_operand" "rI")) 11110 (const_int 0)))] 11111 "" 11112 "...") 11113 11114 The `SELECT_CC_MODE' macro on the SPARC returns `CC_NOOVmode' for 11115comparisons whose argument is a `plus'. 11116 11117 11118File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 11119 1112010.12 Defining Looping Instruction Patterns 11121=========================================== 11122 11123Some machines have special jump instructions that can be utilized to 11124make loops more efficient. A common example is the 68000 `dbra' 11125instruction which performs a decrement of a register and a branch if the 11126result was greater than zero. Other machines, in particular digital 11127signal processors (DSPs), have special block repeat instructions to 11128provide low-overhead loop support. For example, the TI TMS320C3x/C4x 11129DSPs have a block repeat instruction that loads special registers to 11130mark the top and end of a loop and to count the number of loop 11131iterations. This avoids the need for fetching and executing a 11132`dbra'-like instruction and avoids pipeline stalls associated with the 11133jump. 11134 11135 GCC has three special named patterns to support low overhead looping. 11136They are `decrement_and_branch_until_zero', `doloop_begin', and 11137`doloop_end'. The first pattern, `decrement_and_branch_until_zero', is 11138not emitted during RTL generation but may be emitted during the 11139instruction combination phase. This requires the assistance of the 11140loop optimizer, using information collected during strength reduction, 11141to reverse a loop to count down to zero. Some targets also require the 11142loop optimizer to add a `REG_NONNEG' note to indicate that the 11143iteration count is always positive. This is needed if the target 11144performs a signed loop termination test. For example, the 68000 uses a 11145pattern similar to the following for its `dbra' instruction: 11146 11147 (define_insn "decrement_and_branch_until_zero" 11148 [(set (pc) 11149 (if_then_else 11150 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 11151 (const_int -1)) 11152 (const_int 0)) 11153 (label_ref (match_operand 1 "" "")) 11154 (pc))) 11155 (set (match_dup 0) 11156 (plus:SI (match_dup 0) 11157 (const_int -1)))] 11158 "find_reg_note (insn, REG_NONNEG, 0)" 11159 "...") 11160 11161 Note that since the insn is both a jump insn and has an output, it 11162must deal with its own reloads, hence the `m' constraints. Also note 11163that since this insn is generated by the instruction combination phase 11164combining two sequential insns together into an implicit parallel insn, 11165the iteration counter needs to be biased by the same amount as the 11166decrement operation, in this case -1. Note that the following similar 11167pattern will not be matched by the combiner. 11168 11169 (define_insn "decrement_and_branch_until_zero" 11170 [(set (pc) 11171 (if_then_else 11172 (ge (match_operand:SI 0 "general_operand" "+d*am") 11173 (const_int 1)) 11174 (label_ref (match_operand 1 "" "")) 11175 (pc))) 11176 (set (match_dup 0) 11177 (plus:SI (match_dup 0) 11178 (const_int -1)))] 11179 "find_reg_note (insn, REG_NONNEG, 0)" 11180 "...") 11181 11182 The other two special looping patterns, `doloop_begin' and 11183`doloop_end', are emitted by the loop optimizer for certain 11184well-behaved loops with a finite number of loop iterations using 11185information collected during strength reduction. 11186 11187 The `doloop_end' pattern describes the actual looping instruction 11188(or the implicit looping operation) and the `doloop_begin' pattern is 11189an optional companion pattern that can be used for initialization 11190needed for some low-overhead looping instructions. 11191 11192 Note that some machines require the actual looping instruction to be 11193emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 11194the true RTL for a looping instruction at the top of the loop can cause 11195problems with flow analysis. So instead, a dummy `doloop' insn is 11196emitted at the end of the loop. The machine dependent reorg pass checks 11197for the presence of this `doloop' insn and then searches back to the 11198top of the loop, where it inserts the true looping insn (provided there 11199are no instructions in the loop which would cause problems). Any 11200additional labels can be emitted at this point. In addition, if the 11201desired special iteration counter register was not allocated, this 11202machine dependent reorg pass could emit a traditional compare and jump 11203instruction pair. 11204 11205 The essential difference between the 11206`decrement_and_branch_until_zero' and the `doloop_end' patterns is that 11207the loop optimizer allocates an additional pseudo register for the 11208latter as an iteration counter. This pseudo register cannot be used 11209within the loop (i.e., general induction variables cannot be derived 11210from it), however, in many cases the loop induction variable may become 11211redundant and removed by the flow pass. 11212 11213 11214File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 11215 1121610.13 Canonicalization of Instructions 11217====================================== 11218 11219There are often cases where multiple RTL expressions could represent an 11220operation performed by a single machine instruction. This situation is 11221most commonly encountered with logical, branch, and multiply-accumulate 11222instructions. In such cases, the compiler attempts to convert these 11223multiple RTL expressions into a single canonical form to reduce the 11224number of insn patterns required. 11225 11226 In addition to algebraic simplifications, following canonicalizations 11227are performed: 11228 11229 * For commutative and comparison operators, a constant is always 11230 made the second operand. If a machine only supports a constant as 11231 the second operand, only patterns that match a constant in the 11232 second operand need be supplied. 11233 11234 For these operators, if only one operand is a `neg', `not', 11235 `mult', `plus', or `minus' expression, it will be the first 11236 operand. 11237 11238 * In combinations of `neg', `mult', `plus', and `minus', the `neg' 11239 operations (if any) will be moved inside the operations as far as 11240 possible. For instance, `(neg (mult A B))' is canonicalized as 11241 `(mult (neg A) B)', but `(plus (mult (neg A) B) C)' is 11242 canonicalized as `(minus A (mult B C))'. 11243 11244 * For the `compare' operator, a constant is always the second operand 11245 on machines where `cc0' is used (*note Jump Patterns::). On other 11246 machines, there are rare cases where the compiler might want to 11247 construct a `compare' with a constant as the first operand. 11248 However, these cases are not common enough for it to be worthwhile 11249 to provide a pattern matching a constant as the first operand 11250 unless the machine actually has such an instruction. 11251 11252 An operand of `neg', `not', `mult', `plus', or `minus' is made the 11253 first operand under the same conditions as above. 11254 11255 * `(minus X (const_int N))' is converted to `(plus X (const_int 11256 -N))'. 11257 11258 * Within address computations (i.e., inside `mem'), a left shift is 11259 converted into the appropriate multiplication by a power of two. 11260 11261 * De`Morgan's Law is used to move bitwise negation inside a bitwise 11262 logical-and or logical-or operation. If this results in only one 11263 operand being a `not' expression, it will be the first one. 11264 11265 A machine that has an instruction that performs a bitwise 11266 logical-and of one operand with the bitwise negation of the other 11267 should specify the pattern for that instruction as 11268 11269 (define_insn "" 11270 [(set (match_operand:M 0 ...) 11271 (and:M (not:M (match_operand:M 1 ...)) 11272 (match_operand:M 2 ...)))] 11273 "..." 11274 "...") 11275 11276 Similarly, a pattern for a "NAND" instruction should be written 11277 11278 (define_insn "" 11279 [(set (match_operand:M 0 ...) 11280 (ior:M (not:M (match_operand:M 1 ...)) 11281 (not:M (match_operand:M 2 ...))))] 11282 "..." 11283 "...") 11284 11285 In both cases, it is not necessary to include patterns for the many 11286 logically equivalent RTL expressions. 11287 11288 * The only possible RTL expressions involving both bitwise 11289 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M 11290 (xor:M X Y))'. 11291 11292 * The sum of three items, one of which is a constant, will only 11293 appear in the form 11294 11295 (plus:M (plus:M X Y) CONSTANT) 11296 11297 * On machines that do not use `cc0', `(compare X (const_int 0))' 11298 will be converted to X. 11299 11300 * Equality comparisons of a group of bits (usually a single bit) 11301 with zero will be written using `zero_extract' rather than the 11302 equivalent `and' or `sign_extract' operations. 11303 11304 11305 11306File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 11307 1130810.14 Defining RTL Sequences for Code Generation 11309================================================ 11310 11311On some target machines, some standard pattern names for RTL generation 11312cannot be handled with single insn, but a sequence of RTL insns can 11313represent them. For these target machines, you can write a 11314`define_expand' to specify how to generate the sequence of RTL. 11315 11316 A `define_expand' is an RTL expression that looks almost like a 11317`define_insn'; but, unlike the latter, a `define_expand' is used only 11318for RTL generation and it can produce more than one RTL insn. 11319 11320 A `define_expand' RTX has four operands: 11321 11322 * The name. Each `define_expand' must have a name, since the only 11323 use for it is to refer to it by name. 11324 11325 * The RTL template. This is a vector of RTL expressions representing 11326 a sequence of separate instructions. Unlike `define_insn', there 11327 is no implicit surrounding `PARALLEL'. 11328 11329 * The condition, a string containing a C expression. This 11330 expression is used to express how the availability of this pattern 11331 depends on subclasses of target machine, selected by command-line 11332 options when GCC is run. This is just like the condition of a 11333 `define_insn' that has a standard name. Therefore, the condition 11334 (if present) may not depend on the data in the insn being matched, 11335 but only the target-machine-type flags. The compiler needs to 11336 test these conditions during initialization in order to learn 11337 exactly which named instructions are available in a particular run. 11338 11339 * The preparation statements, a string containing zero or more C 11340 statements which are to be executed before RTL code is generated 11341 from the RTL template. 11342 11343 Usually these statements prepare temporary registers for use as 11344 internal operands in the RTL template, but they can also generate 11345 RTL insns directly by calling routines such as `emit_insn', etc. 11346 Any such insns precede the ones that come from the RTL template. 11347 11348 Every RTL insn emitted by a `define_expand' must match some 11349`define_insn' in the machine description. Otherwise, the compiler will 11350crash when trying to generate code for the insn or trying to optimize 11351it. 11352 11353 The RTL template, in addition to controlling generation of RTL insns, 11354also describes the operands that need to be specified when this pattern 11355is used. In particular, it gives a predicate for each operand. 11356 11357 A true operand, which needs to be specified in order to generate RTL 11358from the pattern, should be described with a `match_operand' in its 11359first occurrence in the RTL template. This enters information on the 11360operand's predicate into the tables that record such things. GCC uses 11361the information to preload the operand into a register if that is 11362required for valid RTL code. If the operand is referred to more than 11363once, subsequent references should use `match_dup'. 11364 11365 The RTL template may also refer to internal "operands" which are 11366temporary registers or labels used only within the sequence made by the 11367`define_expand'. Internal operands are substituted into the RTL 11368template with `match_dup', never with `match_operand'. The values of 11369the internal operands are not passed in as arguments by the compiler 11370when it requests use of this pattern. Instead, they are computed 11371within the pattern, in the preparation statements. These statements 11372compute the values and store them into the appropriate elements of 11373`operands' so that `match_dup' can find them. 11374 11375 There are two special macros defined for use in the preparation 11376statements: `DONE' and `FAIL'. Use them with a following semicolon, as 11377a statement. 11378 11379`DONE' 11380 Use the `DONE' macro to end RTL generation for the pattern. The 11381 only RTL insns resulting from the pattern on this occasion will be 11382 those already emitted by explicit calls to `emit_insn' within the 11383 preparation statements; the RTL template will not be generated. 11384 11385`FAIL' 11386 Make the pattern fail on this occasion. When a pattern fails, it 11387 means that the pattern was not truly available. The calling 11388 routines in the compiler will try other strategies for code 11389 generation using other patterns. 11390 11391 Failure is currently supported only for binary (addition, 11392 multiplication, shifting, etc.) and bit-field (`extv', `extzv', 11393 and `insv') operations. 11394 11395 If the preparation falls through (invokes neither `DONE' nor 11396`FAIL'), then the `define_expand' acts like a `define_insn' in that the 11397RTL template is used to generate the insn. 11398 11399 The RTL template is not used for matching, only for generating the 11400initial insn list. If the preparation statement always invokes `DONE' 11401or `FAIL', the RTL template may be reduced to a simple list of 11402operands, such as this example: 11403 11404 (define_expand "addsi3" 11405 [(match_operand:SI 0 "register_operand" "") 11406 (match_operand:SI 1 "register_operand" "") 11407 (match_operand:SI 2 "register_operand" "")] 11408 "" 11409 " 11410 { 11411 handle_add (operands[0], operands[1], operands[2]); 11412 DONE; 11413 }") 11414 11415 Here is an example, the definition of left-shift for the SPUR chip: 11416 11417 (define_expand "ashlsi3" 11418 [(set (match_operand:SI 0 "register_operand" "") 11419 (ashift:SI 11420 (match_operand:SI 1 "register_operand" "") 11421 (match_operand:SI 2 "nonmemory_operand" "")))] 11422 "" 11423 " 11424 11425 { 11426 if (GET_CODE (operands[2]) != CONST_INT 11427 || (unsigned) INTVAL (operands[2]) > 3) 11428 FAIL; 11429 }") 11430 11431This example uses `define_expand' so that it can generate an RTL insn 11432for shifting when the shift-count is in the supported range of 0 to 3 11433but fail in other cases where machine insns aren't available. When it 11434fails, the compiler tries another strategy using different patterns 11435(such as, a library call). 11436 11437 If the compiler were able to handle nontrivial condition-strings in 11438patterns with names, then it would be possible to use a `define_insn' 11439in that case. Here is another case (zero-extension on the 68000) which 11440makes more use of the power of `define_expand': 11441 11442 (define_expand "zero_extendhisi2" 11443 [(set (match_operand:SI 0 "general_operand" "") 11444 (const_int 0)) 11445 (set (strict_low_part 11446 (subreg:HI 11447 (match_dup 0) 11448 0)) 11449 (match_operand:HI 1 "general_operand" ""))] 11450 "" 11451 "operands[1] = make_safe_from (operands[1], operands[0]);") 11452 11453Here two RTL insns are generated, one to clear the entire output operand 11454and the other to copy the input operand into its low half. This 11455sequence is incorrect if the input operand refers to [the old value of] 11456the output operand, so the preparation statement makes sure this isn't 11457so. The function `make_safe_from' copies the `operands[1]' into a 11458temporary register if it refers to `operands[0]'. It does this by 11459emitting another RTL insn. 11460 11461 Finally, a third example shows the use of an internal operand. 11462Zero-extension on the SPUR chip is done by `and'-ing the result against 11463a halfword mask. But this mask cannot be represented by a `const_int' 11464because the constant value is too large to be legitimate on this 11465machine. So it must be copied into a register with `force_reg' and 11466then the register used in the `and'. 11467 11468 (define_expand "zero_extendhisi2" 11469 [(set (match_operand:SI 0 "register_operand" "") 11470 (and:SI (subreg:SI 11471 (match_operand:HI 1 "register_operand" "") 11472 0) 11473 (match_dup 2)))] 11474 "" 11475 "operands[2] 11476 = force_reg (SImode, GEN_INT (65535)); ") 11477 11478 *Note:* If the `define_expand' is used to serve a standard binary or 11479unary arithmetic operation or a bit-field operation, then the last insn 11480it generates must not be a `code_label', `barrier' or `note'. It must 11481be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 11482at the end, emit an insn to copy the result of the operation into 11483itself. Such an insn will generate no code, but it can avoid problems 11484in the compiler. 11485 11486 11487File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 11488 1148910.15 Defining How to Split Instructions 11490======================================== 11491 11492There are two cases where you should specify how to split a pattern 11493into multiple insns. On machines that have instructions requiring 11494delay slots (*note Delay Slots::) or that have instructions whose 11495output is not available for multiple cycles (*note Processor pipeline 11496description::), the compiler phases that optimize these cases need to 11497be able to move insns into one-instruction delay slots. However, some 11498insns may generate more than one machine instruction. These insns 11499cannot be placed into a delay slot. 11500 11501 Often you can rewrite the single insn as a list of individual insns, 11502each corresponding to one machine instruction. The disadvantage of 11503doing so is that it will cause the compilation to be slower and require 11504more space. If the resulting insns are too complex, it may also 11505suppress some optimizations. The compiler splits the insn if there is a 11506reason to believe that it might improve instruction or delay slot 11507scheduling. 11508 11509 The insn combiner phase also splits putative insns. If three insns 11510are merged into one insn with a complex expression that cannot be 11511matched by some `define_insn' pattern, the combiner phase attempts to 11512split the complex pattern into two insns that are recognized. Usually 11513it can break the complex pattern into two patterns by splitting out some 11514subexpression. However, in some other cases, such as performing an 11515addition of a large constant in two insns on a RISC machine, the way to 11516split the addition into two insns is machine-dependent. 11517 11518 The `define_split' definition tells the compiler how to split a 11519complex insn into several simpler insns. It looks like this: 11520 11521 (define_split 11522 [INSN-PATTERN] 11523 "CONDITION" 11524 [NEW-INSN-PATTERN-1 11525 NEW-INSN-PATTERN-2 11526 ...] 11527 "PREPARATION-STATEMENTS") 11528 11529 INSN-PATTERN is a pattern that needs to be split and CONDITION is 11530the final condition to be tested, as in a `define_insn'. When an insn 11531matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 11532in the insn list with the insns given by NEW-INSN-PATTERN-1, 11533NEW-INSN-PATTERN-2, etc. 11534 11535 The PREPARATION-STATEMENTS are similar to those statements that are 11536specified for `define_expand' (*note Expander Definitions::) and are 11537executed before the new RTL is generated to prepare for the generated 11538code or emit some insns whose pattern is not fixed. Unlike those in 11539`define_expand', however, these statements must not generate any new 11540pseudo-registers. Once reload has completed, they also must not 11541allocate any space in the stack frame. 11542 11543 Patterns are matched against INSN-PATTERN in two different 11544circumstances. If an insn needs to be split for delay slot scheduling 11545or insn scheduling, the insn is already known to be valid, which means 11546that it must have been matched by some `define_insn' and, if 11547`reload_completed' is nonzero, is known to satisfy the constraints of 11548that `define_insn'. In that case, the new insn patterns must also be 11549insns that are matched by some `define_insn' and, if `reload_completed' 11550is nonzero, must also satisfy the constraints of those definitions. 11551 11552 As an example of this usage of `define_split', consider the following 11553example from `a29k.md', which splits a `sign_extend' from `HImode' to 11554`SImode' into a pair of shift insns: 11555 11556 (define_split 11557 [(set (match_operand:SI 0 "gen_reg_operand" "") 11558 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 11559 "" 11560 [(set (match_dup 0) 11561 (ashift:SI (match_dup 1) 11562 (const_int 16))) 11563 (set (match_dup 0) 11564 (ashiftrt:SI (match_dup 0) 11565 (const_int 16)))] 11566 " 11567 { operands[1] = gen_lowpart (SImode, operands[1]); }") 11568 11569 When the combiner phase tries to split an insn pattern, it is always 11570the case that the pattern is _not_ matched by any `define_insn'. The 11571combiner pass first tries to split a single `set' expression and then 11572the same `set' expression inside a `parallel', but followed by a 11573`clobber' of a pseudo-reg to use as a scratch register. In these 11574cases, the combiner expects exactly two new insn patterns to be 11575generated. It will verify that these patterns match some `define_insn' 11576definitions, so you need not do this test in the `define_split' (of 11577course, there is no point in writing a `define_split' that will never 11578produce insns that match). 11579 11580 Here is an example of this use of `define_split', taken from 11581`rs6000.md': 11582 11583 (define_split 11584 [(set (match_operand:SI 0 "gen_reg_operand" "") 11585 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 11586 (match_operand:SI 2 "non_add_cint_operand" "")))] 11587 "" 11588 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 11589 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 11590 " 11591 { 11592 int low = INTVAL (operands[2]) & 0xffff; 11593 int high = (unsigned) INTVAL (operands[2]) >> 16; 11594 11595 if (low & 0x8000) 11596 high++, low |= 0xffff0000; 11597 11598 operands[3] = GEN_INT (high << 16); 11599 operands[4] = GEN_INT (low); 11600 }") 11601 11602 Here the predicate `non_add_cint_operand' matches any `const_int' 11603that is _not_ a valid operand of a single add insn. The add with the 11604smaller displacement is written so that it can be substituted into the 11605address of a subsequent operation. 11606 11607 An example that uses a scratch register, from the same file, 11608generates an equality comparison of a register and a large constant: 11609 11610 (define_split 11611 [(set (match_operand:CC 0 "cc_reg_operand" "") 11612 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 11613 (match_operand:SI 2 "non_short_cint_operand" ""))) 11614 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 11615 "find_single_use (operands[0], insn, 0) 11616 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 11617 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 11618 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 11619 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 11620 " 11621 { 11622 /* Get the constant we are comparing against, C, and see what it 11623 looks like sign-extended to 16 bits. Then see what constant 11624 could be XOR'ed with C to get the sign-extended value. */ 11625 11626 int c = INTVAL (operands[2]); 11627 int sextc = (c << 16) >> 16; 11628 int xorv = c ^ sextc; 11629 11630 operands[4] = GEN_INT (xorv); 11631 operands[5] = GEN_INT (sextc); 11632 }") 11633 11634 To avoid confusion, don't write a single `define_split' that accepts 11635some insns that match some `define_insn' as well as some insns that 11636don't. Instead, write two separate `define_split' definitions, one for 11637the insns that are valid and one for the insns that are not valid. 11638 11639 The splitter is allowed to split jump instructions into sequence of 11640jumps or create new jumps in while splitting non-jump instructions. As 11641the central flowgraph and branch prediction information needs to be 11642updated, several restriction apply. 11643 11644 Splitting of jump instruction into sequence that over by another jump 11645instruction is always valid, as compiler expect identical behavior of 11646new jump. When new sequence contains multiple jump instructions or new 11647labels, more assistance is needed. Splitter is required to create only 11648unconditional jumps, or simple conditional jump instructions. 11649Additionally it must attach a `REG_BR_PROB' note to each conditional 11650jump. A global variable `split_branch_probability' hold the 11651probability of original branch in case it was an simple conditional 11652jump, -1 otherwise. To simplify recomputing of edge frequencies, new 11653sequence is required to have only forward jumps to the newly created 11654labels. 11655 11656 For the common case where the pattern of a define_split exactly 11657matches the pattern of a define_insn, use `define_insn_and_split'. It 11658looks like this: 11659 11660 (define_insn_and_split 11661 [INSN-PATTERN] 11662 "CONDITION" 11663 "OUTPUT-TEMPLATE" 11664 "SPLIT-CONDITION" 11665 [NEW-INSN-PATTERN-1 11666 NEW-INSN-PATTERN-2 11667 ...] 11668 "PREPARATION-STATEMENTS" 11669 [INSN-ATTRIBUTES]) 11670 11671 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are 11672used as in `define_insn'. The NEW-INSN-PATTERN vector and the 11673PREPARATION-STATEMENTS are used as in a `define_split'. The 11674SPLIT-CONDITION is also used as in `define_split', with the additional 11675behavior that if the condition starts with `&&', the condition used for 11676the split will be the constructed as a logical "and" of the split 11677condition with the insn condition. For example, from i386.md: 11678 11679 (define_insn_and_split "zero_extendhisi2_and" 11680 [(set (match_operand:SI 0 "register_operand" "=r") 11681 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 11682 (clobber (reg:CC 17))] 11683 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 11684 "#" 11685 "&& reload_completed" 11686 [(parallel [(set (match_dup 0) 11687 (and:SI (match_dup 0) (const_int 65535))) 11688 (clobber (reg:CC 17))])] 11689 "" 11690 [(set_attr "type" "alu1")]) 11691 11692 In this case, the actual split condition will be 11693`TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 11694 11695 The `define_insn_and_split' construction provides exactly the same 11696functionality as two separate `define_insn' and `define_split' 11697patterns. It exists for compactness, and as a maintenance tool to 11698prevent having to ensure the two patterns' templates match. 11699 11700 11701File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 11702 1170310.16 Including Patterns in Machine Descriptions. 11704================================================= 11705 11706The `include' pattern tells the compiler tools where to look for 11707patterns that are in files other than in the file `.md'. This is used 11708only at build time and there is no preprocessing allowed. 11709 11710 It looks like: 11711 11712 11713 (include 11714 PATHNAME) 11715 11716 For example: 11717 11718 11719 (include "filestuff") 11720 11721 Where PATHNAME is a string that specifies the location of the file, 11722specifies the include file to be in `gcc/config/target/filestuff'. The 11723directory `gcc/config/target' is regarded as the default directory. 11724 11725 Machine descriptions may be split up into smaller more manageable 11726subsections and placed into subdirectories. 11727 11728 By specifying: 11729 11730 11731 (include "BOGUS/filestuff") 11732 11733 the include file is specified to be in 11734`gcc/config/TARGET/BOGUS/filestuff'. 11735 11736 Specifying an absolute path for the include file such as; 11737 11738 (include "/u2/BOGUS/filestuff") 11739 is permitted but is not encouraged. 11740 1174110.16.1 RTL Generation Tool Options for Directory Search 11742-------------------------------------------------------- 11743 11744The `-IDIR' option specifies directories to search for machine 11745descriptions. For example: 11746 11747 11748 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 11749 11750 Add the directory DIR to the head of the list of directories to be 11751searched for header files. This can be used to override a system 11752machine definition file, substituting your own version, since these 11753directories are searched before the default machine description file 11754directories. If you use more than one `-I' option, the directories are 11755scanned in left-to-right order; the standard default directory come 11756after. 11757 11758 11759File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 11760 1176110.17 Machine-Specific Peephole Optimizers 11762========================================== 11763 11764In addition to instruction patterns the `md' file may contain 11765definitions of machine-specific peephole optimizations. 11766 11767 The combiner does not notice certain peephole optimizations when the 11768data flow in the program does not suggest that it should try them. For 11769example, sometimes two consecutive insns related in purpose can be 11770combined even though the second one does not appear to use a register 11771computed in the first one. A machine-specific peephole optimizer can 11772detect such opportunities. 11773 11774 There are two forms of peephole definitions that may be used. The 11775original `define_peephole' is run at assembly output time to match 11776insns and substitute assembly text. Use of `define_peephole' is 11777deprecated. 11778 11779 A newer `define_peephole2' matches insns and substitutes new insns. 11780The `peephole2' pass is run after register allocation but before 11781scheduling, which may result in much better code for targets that do 11782scheduling. 11783 11784* Menu: 11785 11786* define_peephole:: RTL to Text Peephole Optimizers 11787* define_peephole2:: RTL to RTL Peephole Optimizers 11788 11789 11790File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 11791 1179210.17.1 RTL to Text Peephole Optimizers 11793--------------------------------------- 11794 11795A definition looks like this: 11796 11797 (define_peephole 11798 [INSN-PATTERN-1 11799 INSN-PATTERN-2 11800 ...] 11801 "CONDITION" 11802 "TEMPLATE" 11803 "OPTIONAL-INSN-ATTRIBUTES") 11804 11805The last string operand may be omitted if you are not using any 11806machine-specific information in this machine description. If present, 11807it must obey the same rules as in a `define_insn'. 11808 11809 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 11810consecutive insns. The optimization applies to a sequence of insns when 11811INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 11812and so on. 11813 11814 Each of the insns matched by a peephole must also match a 11815`define_insn'. Peepholes are checked only at the last stage just 11816before code generation, and only optionally. Therefore, any insn which 11817would match a peephole but no `define_insn' will cause a crash in code 11818generation in an unoptimized compilation, or at various optimization 11819stages. 11820 11821 The operands of the insns are matched with `match_operands', 11822`match_operator', and `match_dup', as usual. What is not usual is that 11823the operand numbers apply to all the insn patterns in the definition. 11824So, you can check for identical operands in two insns by using 11825`match_operand' in one insn and `match_dup' in the other. 11826 11827 The operand constraints used in `match_operand' patterns do not have 11828any direct effect on the applicability of the peephole, but they will 11829be validated afterward, so make sure your constraints are general enough 11830to apply whenever the peephole matches. If the peephole matches but 11831the constraints are not satisfied, the compiler will crash. 11832 11833 It is safe to omit constraints in all the operands of the peephole; 11834or you can write constraints which serve as a double-check on the 11835criteria previously tested. 11836 11837 Once a sequence of insns matches the patterns, the CONDITION is 11838checked. This is a C expression which makes the final decision whether 11839to perform the optimization (we do so if the expression is nonzero). If 11840CONDITION is omitted (in other words, the string is empty) then the 11841optimization is applied to every sequence of insns that matches the 11842patterns. 11843 11844 The defined peephole optimizations are applied after register 11845allocation is complete. Therefore, the peephole definition can check 11846which operands have ended up in which kinds of registers, just by 11847looking at the operands. 11848 11849 The way to refer to the operands in CONDITION is to write 11850`operands[I]' for operand number I (as matched by `(match_operand I 11851...)'). Use the variable `insn' to refer to the last of the insns 11852being matched; use `prev_active_insn' to find the preceding insns. 11853 11854 When optimizing computations with intermediate results, you can use 11855CONDITION to match only when the intermediate results are not used 11856elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN 11857is the insn in which you expect the value to be used for the last time 11858(from the value of `insn', together with use of `prev_nonnote_insn'), 11859and OP is the intermediate value (from `operands[I]'). 11860 11861 Applying the optimization means replacing the sequence of insns with 11862one new insn. The TEMPLATE controls ultimate output of assembler code 11863for this combined insn. It works exactly like the template of a 11864`define_insn'. Operand numbers in this template are the same ones used 11865in matching the original sequence of insns. 11866 11867 The result of a defined peephole optimizer does not need to match 11868any of the insn patterns in the machine description; it does not even 11869have an opportunity to match them. The peephole optimizer definition 11870itself serves as the insn pattern to control how the insn is output. 11871 11872 Defined peephole optimizers are run as assembler code is being 11873output, so the insns they produce are never combined or rearranged in 11874any way. 11875 11876 Here is an example, taken from the 68000 machine description: 11877 11878 (define_peephole 11879 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 11880 (set (match_operand:DF 0 "register_operand" "=f") 11881 (match_operand:DF 1 "register_operand" "ad"))] 11882 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 11883 { 11884 rtx xoperands[2]; 11885 xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); 11886 #ifdef MOTOROLA 11887 output_asm_insn ("move.l %1,(sp)", xoperands); 11888 output_asm_insn ("move.l %1,-(sp)", operands); 11889 return "fmove.d (sp)+,%0"; 11890 #else 11891 output_asm_insn ("movel %1,sp@", xoperands); 11892 output_asm_insn ("movel %1,sp@-", operands); 11893 return "fmoved sp@+,%0"; 11894 #endif 11895 }) 11896 11897 The effect of this optimization is to change 11898 11899 jbsr _foobar 11900 addql #4,sp 11901 movel d1,sp@- 11902 movel d0,sp@- 11903 fmoved sp@+,fp0 11904 11905into 11906 11907 jbsr _foobar 11908 movel d1,sp@ 11909 movel d0,sp@- 11910 fmoved sp@+,fp0 11911 11912 INSN-PATTERN-1 and so on look _almost_ like the second operand of 11913`define_insn'. There is one important difference: the second operand 11914of `define_insn' consists of one or more RTX's enclosed in square 11915brackets. Usually, there is only one: then the same action can be 11916written as an element of a `define_peephole'. But when there are 11917multiple actions in a `define_insn', they are implicitly enclosed in a 11918`parallel'. Then you must explicitly write the `parallel', and the 11919square brackets within it, in the `define_peephole'. Thus, if an insn 11920pattern looks like this, 11921 11922 (define_insn "divmodsi4" 11923 [(set (match_operand:SI 0 "general_operand" "=d") 11924 (div:SI (match_operand:SI 1 "general_operand" "0") 11925 (match_operand:SI 2 "general_operand" "dmsK"))) 11926 (set (match_operand:SI 3 "general_operand" "=d") 11927 (mod:SI (match_dup 1) (match_dup 2)))] 11928 "TARGET_68020" 11929 "divsl%.l %2,%3:%0") 11930 11931then the way to mention this insn in a peephole is as follows: 11932 11933 (define_peephole 11934 [... 11935 (parallel 11936 [(set (match_operand:SI 0 "general_operand" "=d") 11937 (div:SI (match_operand:SI 1 "general_operand" "0") 11938 (match_operand:SI 2 "general_operand" "dmsK"))) 11939 (set (match_operand:SI 3 "general_operand" "=d") 11940 (mod:SI (match_dup 1) (match_dup 2)))]) 11941 ...] 11942 ...) 11943 11944 11945File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 11946 1194710.17.2 RTL to RTL Peephole Optimizers 11948-------------------------------------- 11949 11950The `define_peephole2' definition tells the compiler how to substitute 11951one sequence of instructions for another sequence, what additional 11952scratch registers may be needed and what their lifetimes must be. 11953 11954 (define_peephole2 11955 [INSN-PATTERN-1 11956 INSN-PATTERN-2 11957 ...] 11958 "CONDITION" 11959 [NEW-INSN-PATTERN-1 11960 NEW-INSN-PATTERN-2 11961 ...] 11962 "PREPARATION-STATEMENTS") 11963 11964 The definition is almost identical to `define_split' (*note Insn 11965Splitting::) except that the pattern to match is not a single 11966instruction, but a sequence of instructions. 11967 11968 It is possible to request additional scratch registers for use in the 11969output template. If appropriate registers are not free, the pattern 11970will simply not match. 11971 11972 Scratch registers are requested with a `match_scratch' pattern at 11973the top level of the input pattern. The allocated register (initially) 11974will be dead at the point requested within the original sequence. If 11975the scratch is used at more than a single point, a `match_dup' pattern 11976at the top level of the input pattern marks the last position in the 11977input sequence at which the register must be available. 11978 11979 Here is an example from the IA-32 machine description: 11980 11981 (define_peephole2 11982 [(match_scratch:SI 2 "r") 11983 (parallel [(set (match_operand:SI 0 "register_operand" "") 11984 (match_operator:SI 3 "arith_or_logical_operator" 11985 [(match_dup 0) 11986 (match_operand:SI 1 "memory_operand" "")])) 11987 (clobber (reg:CC 17))])] 11988 "! optimize_size && ! TARGET_READ_MODIFY" 11989 [(set (match_dup 2) (match_dup 1)) 11990 (parallel [(set (match_dup 0) 11991 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 11992 (clobber (reg:CC 17))])] 11993 "") 11994 11995This pattern tries to split a load from its use in the hopes that we'll 11996be able to schedule around the memory load latency. It allocates a 11997single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to 11998be live only at the point just before the arithmetic. 11999 12000 A real example requiring extended scratch lifetimes is harder to 12001come by, so here's a silly made-up example: 12002 12003 (define_peephole2 12004 [(match_scratch:SI 4 "r") 12005 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 12006 (set (match_operand:SI 2 "" "") (match_dup 1)) 12007 (match_dup 4) 12008 (set (match_operand:SI 3 "" "") (match_dup 1))] 12009 "/* determine 1 does not overlap 0 and 2 */" 12010 [(set (match_dup 4) (match_dup 1)) 12011 (set (match_dup 0) (match_dup 4)) 12012 (set (match_dup 2) (match_dup 4))] 12013 (set (match_dup 3) (match_dup 4))] 12014 "") 12015 12016If we had not added the `(match_dup 4)' in the middle of the input 12017sequence, it might have been the case that the register we chose at the 12018beginning of the sequence is killed by the first or second `set'. 12019 12020 12021File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 12022 1202310.18 Instruction Attributes 12024============================ 12025 12026In addition to describing the instruction supported by the target 12027machine, the `md' file also defines a group of "attributes" and a set of 12028values for each. Every generated insn is assigned a value for each 12029attribute. One possible attribute would be the effect that the insn 12030has on the machine's condition code. This attribute can then be used 12031by `NOTICE_UPDATE_CC' to track the condition codes. 12032 12033* Menu: 12034 12035* Defining Attributes:: Specifying attributes and their values. 12036* Expressions:: Valid expressions for attribute values. 12037* Tagging Insns:: Assigning attribute values to insns. 12038* Attr Example:: An example of assigning attributes. 12039* Insn Lengths:: Computing the length of insns. 12040* Constant Attributes:: Defining attributes that are constant. 12041* Delay Slots:: Defining delay slots required for a machine. 12042* Processor pipeline description:: Specifying information for insn scheduling. 12043 12044 12045File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 12046 1204710.18.1 Defining Attributes and their Values 12048-------------------------------------------- 12049 12050The `define_attr' expression is used to define each attribute required 12051by the target machine. It looks like: 12052 12053 (define_attr NAME LIST-OF-VALUES DEFAULT) 12054 12055 NAME is a string specifying the name of the attribute being defined. 12056 12057 LIST-OF-VALUES is either a string that specifies a comma-separated 12058list of values that can be assigned to the attribute, or a null string 12059to indicate that the attribute takes numeric values. 12060 12061 DEFAULT is an attribute expression that gives the value of this 12062attribute for insns that match patterns whose definition does not 12063include an explicit value for this attribute. *Note Attr Example::, 12064for more information on the handling of defaults. *Note Constant 12065Attributes::, for information on attributes that do not depend on any 12066particular insn. 12067 12068 For each defined attribute, a number of definitions are written to 12069the `insn-attr.h' file. For cases where an explicit set of values is 12070specified for an attribute, the following are defined: 12071 12072 * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 12073 12074 * An enumerated class is defined for `attr_NAME' with elements of 12075 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and 12076 value are first converted to uppercase. 12077 12078 * A function `get_attr_NAME' is defined that is passed an insn and 12079 returns the attribute value for that insn. 12080 12081 For example, if the following is present in the `md' file: 12082 12083 (define_attr "type" "branch,fp,load,store,arith" ...) 12084 12085the following lines will be written to the file `insn-attr.h'. 12086 12087 #define HAVE_ATTR_type 12088 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 12089 TYPE_STORE, TYPE_ARITH}; 12090 extern enum attr_type get_attr_type (); 12091 12092 If the attribute takes numeric values, no `enum' type will be 12093defined and the function to obtain the attribute's value will return 12094`int'. 12095 12096 12097File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 12098 1209910.18.2 Attribute Expressions 12100----------------------------- 12101 12102RTL expressions used to define attributes use the codes described above 12103plus a few specific to attribute definitions, to be discussed below. 12104Attribute value expressions must have one of the following forms: 12105 12106`(const_int I)' 12107 The integer I specifies the value of a numeric attribute. I must 12108 be non-negative. 12109 12110 The value of a numeric attribute can be specified either with a 12111 `const_int', or as an integer represented as a string in 12112 `const_string', `eq_attr' (see below), `attr', `symbol_ref', 12113 simple arithmetic expressions, and `set_attr' overrides on 12114 specific instructions (*note Tagging Insns::). 12115 12116`(const_string VALUE)' 12117 The string VALUE specifies a constant attribute value. If VALUE 12118 is specified as `"*"', it means that the default value of the 12119 attribute is to be used for the insn containing this expression. 12120 `"*"' obviously cannot be used in the DEFAULT expression of a 12121 `define_attr'. 12122 12123 If the attribute whose value is being specified is numeric, VALUE 12124 must be a string containing a non-negative integer (normally 12125 `const_int' would be used in this case). Otherwise, it must 12126 contain one of the valid values for the attribute. 12127 12128`(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 12129 TEST specifies an attribute test, whose format is defined below. 12130 The value of this expression is TRUE-VALUE if TEST is true, 12131 otherwise it is FALSE-VALUE. 12132 12133`(cond [TEST1 VALUE1 ...] DEFAULT)' 12134 The first operand of this expression is a vector containing an even 12135 number of expressions and consisting of pairs of TEST and VALUE 12136 expressions. The value of the `cond' expression is that of the 12137 VALUE corresponding to the first true TEST expression. If none of 12138 the TEST expressions are true, the value of the `cond' expression 12139 is that of the DEFAULT expression. 12140 12141 TEST expressions can have one of the following forms: 12142 12143`(const_int I)' 12144 This test is true if I is nonzero and false otherwise. 12145 12146`(not TEST)' 12147`(ior TEST1 TEST2)' 12148`(and TEST1 TEST2)' 12149 These tests are true if the indicated logical function is true. 12150 12151`(match_operand:M N PRED CONSTRAINTS)' 12152 This test is true if operand N of the insn whose attribute value 12153 is being determined has mode M (this part of the test is ignored 12154 if M is `VOIDmode') and the function specified by the string PRED 12155 returns a nonzero value when passed operand N and mode M (this 12156 part of the test is ignored if PRED is the null string). 12157 12158 The CONSTRAINTS operand is ignored and should be the null string. 12159 12160`(le ARITH1 ARITH2)' 12161`(leu ARITH1 ARITH2)' 12162`(lt ARITH1 ARITH2)' 12163`(ltu ARITH1 ARITH2)' 12164`(gt ARITH1 ARITH2)' 12165`(gtu ARITH1 ARITH2)' 12166`(ge ARITH1 ARITH2)' 12167`(geu ARITH1 ARITH2)' 12168`(ne ARITH1 ARITH2)' 12169`(eq ARITH1 ARITH2)' 12170 These tests are true if the indicated comparison of the two 12171 arithmetic expressions is true. Arithmetic expressions are formed 12172 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 12173 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 12174 expressions. 12175 12176 `const_int' and `symbol_ref' are always valid terms (*note Insn 12177 Lengths::,for additional forms). `symbol_ref' is a string 12178 denoting a C expression that yields an `int' when evaluated by the 12179 `get_attr_...' routine. It should normally be a global variable. 12180 12181`(eq_attr NAME VALUE)' 12182 NAME is a string specifying the name of an attribute. 12183 12184 VALUE is a string that is either a valid value for attribute NAME, 12185 a comma-separated list of values, or `!' followed by a value or 12186 list. If VALUE does not begin with a `!', this test is true if 12187 the value of the NAME attribute of the current insn is in the list 12188 specified by VALUE. If VALUE begins with a `!', this test is true 12189 if the attribute's value is _not_ in the specified list. 12190 12191 For example, 12192 12193 (eq_attr "type" "load,store") 12194 12195 is equivalent to 12196 12197 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 12198 12199 If NAME specifies an attribute of `alternative', it refers to the 12200 value of the compiler variable `which_alternative' (*note Output 12201 Statement::) and the values must be small integers. For example, 12202 12203 (eq_attr "alternative" "2,3") 12204 12205 is equivalent to 12206 12207 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 12208 (eq (symbol_ref "which_alternative") (const_int 3))) 12209 12210 Note that, for most attributes, an `eq_attr' test is simplified in 12211 cases where the value of the attribute being tested is known for 12212 all insns matching a particular pattern. This is by far the most 12213 common case. 12214 12215`(attr_flag NAME)' 12216 The value of an `attr_flag' expression is true if the flag 12217 specified by NAME is true for the `insn' currently being scheduled. 12218 12219 NAME is a string specifying one of a fixed set of flags to test. 12220 Test the flags `forward' and `backward' to determine the direction 12221 of a conditional branch. Test the flags `very_likely', `likely', 12222 `very_unlikely', and `unlikely' to determine if a conditional 12223 branch is expected to be taken. 12224 12225 If the `very_likely' flag is true, then the `likely' flag is also 12226 true. Likewise for the `very_unlikely' and `unlikely' flags. 12227 12228 This example describes a conditional branch delay slot which can 12229 be nullified for forward branches that are taken (annul-true) or 12230 for backward branches which are not taken (annul-false). 12231 12232 (define_delay (eq_attr "type" "cbranch") 12233 [(eq_attr "in_branch_delay" "true") 12234 (and (eq_attr "in_branch_delay" "true") 12235 (attr_flag "forward")) 12236 (and (eq_attr "in_branch_delay" "true") 12237 (attr_flag "backward"))]) 12238 12239 The `forward' and `backward' flags are false if the current `insn' 12240 being scheduled is not a conditional branch. 12241 12242 The `very_likely' and `likely' flags are true if the `insn' being 12243 scheduled is not a conditional branch. The `very_unlikely' and 12244 `unlikely' flags are false if the `insn' being scheduled is not a 12245 conditional branch. 12246 12247 `attr_flag' is only used during delay slot scheduling and has no 12248 meaning to other passes of the compiler. 12249 12250`(attr NAME)' 12251 The value of another attribute is returned. This is most useful 12252 for numeric attributes, as `eq_attr' and `attr_flag' produce more 12253 efficient code for non-numeric attributes. 12254 12255 12256File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 12257 1225810.18.3 Assigning Attribute Values to Insns 12259------------------------------------------- 12260 12261The value assigned to an attribute of an insn is primarily determined by 12262which pattern is matched by that insn (or which `define_peephole' 12263generated it). Every `define_insn' and `define_peephole' can have an 12264optional last argument to specify the values of attributes for matching 12265insns. The value of any attribute not specified in a particular insn 12266is set to the default value for that attribute, as specified in its 12267`define_attr'. Extensive use of default values for attributes permits 12268the specification of the values for only one or two attributes in the 12269definition of most insn patterns, as seen in the example in the next 12270section. 12271 12272 The optional last argument of `define_insn' and `define_peephole' is 12273a vector of expressions, each of which defines the value for a single 12274attribute. The most general way of assigning an attribute's value is 12275to use a `set' expression whose first operand is an `attr' expression 12276giving the name of the attribute being set. The second operand of the 12277`set' is an attribute expression (*note Expressions::) giving the value 12278of the attribute. 12279 12280 When the attribute value depends on the `alternative' attribute 12281(i.e., which is the applicable alternative in the constraint of the 12282insn), the `set_attr_alternative' expression can be used. It allows 12283the specification of a vector of attribute expressions, one for each 12284alternative. 12285 12286 When the generality of arbitrary attribute expressions is not 12287required, the simpler `set_attr' expression can be used, which allows 12288specifying a string giving either a single attribute value or a list of 12289attribute values, one for each alternative. 12290 12291 The form of each of the above specifications is shown below. In 12292each case, NAME is a string specifying the attribute to be set. 12293 12294`(set_attr NAME VALUE-STRING)' 12295 VALUE-STRING is either a string giving the desired attribute value, 12296 or a string containing a comma-separated list giving the values for 12297 succeeding alternatives. The number of elements must match the 12298 number of alternatives in the constraint of the insn pattern. 12299 12300 Note that it may be useful to specify `*' for some alternative, in 12301 which case the attribute will assume its default value for insns 12302 matching that alternative. 12303 12304`(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 12305 Depending on the alternative of the insn, the value will be one of 12306 the specified values. This is a shorthand for using a `cond' with 12307 tests on the `alternative' attribute. 12308 12309`(set (attr NAME) VALUE)' 12310 The first operand of this `set' must be the special RTL expression 12311 `attr', whose sole operand is a string giving the name of the 12312 attribute being set. VALUE is the value of the attribute. 12313 12314 The following shows three different ways of representing the same 12315attribute value specification: 12316 12317 (set_attr "type" "load,store,arith") 12318 12319 (set_attr_alternative "type" 12320 [(const_string "load") (const_string "store") 12321 (const_string "arith")]) 12322 12323 (set (attr "type") 12324 (cond [(eq_attr "alternative" "1") (const_string "load") 12325 (eq_attr "alternative" "2") (const_string "store")] 12326 (const_string "arith"))) 12327 12328 The `define_asm_attributes' expression provides a mechanism to 12329specify the attributes assigned to insns produced from an `asm' 12330statement. It has the form: 12331 12332 (define_asm_attributes [ATTR-SETS]) 12333 12334where ATTR-SETS is specified the same as for both the `define_insn' and 12335the `define_peephole' expressions. 12336 12337 These values will typically be the "worst case" attribute values. 12338For example, they might indicate that the condition code will be 12339clobbered. 12340 12341 A specification for a `length' attribute is handled specially. The 12342way to compute the length of an `asm' insn is to multiply the length 12343specified in the expression `define_asm_attributes' by the number of 12344machine instructions specified in the `asm' statement, determined by 12345counting the number of semicolons and newlines in the string. 12346Therefore, the value of the `length' attribute specified in a 12347`define_asm_attributes' should be the maximum possible length of a 12348single machine instruction. 12349 12350 12351File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 12352 1235310.18.4 Example of Attribute Specifications 12354------------------------------------------- 12355 12356The judicious use of defaulting is important in the efficient use of 12357insn attributes. Typically, insns are divided into "types" and an 12358attribute, customarily called `type', is used to represent this value. 12359This attribute is normally used only to define the default value for 12360other attributes. An example will clarify this usage. 12361 12362 Assume we have a RISC machine with a condition code and in which only 12363full-word operations are performed in registers. Let us assume that we 12364can divide all insns into loads, stores, (integer) arithmetic 12365operations, floating point operations, and branches. 12366 12367 Here we will concern ourselves with determining the effect of an 12368insn on the condition code and will limit ourselves to the following 12369possible effects: The condition code can be set unpredictably 12370(clobbered), not be changed, be set to agree with the results of the 12371operation, or only changed if the item previously set into the 12372condition code has been modified. 12373 12374 Here is part of a sample `md' file for such a machine: 12375 12376 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 12377 12378 (define_attr "cc" "clobber,unchanged,set,change0" 12379 (cond [(eq_attr "type" "load") 12380 (const_string "change0") 12381 (eq_attr "type" "store,branch") 12382 (const_string "unchanged") 12383 (eq_attr "type" "arith") 12384 (if_then_else (match_operand:SI 0 "" "") 12385 (const_string "set") 12386 (const_string "clobber"))] 12387 (const_string "clobber"))) 12388 12389 (define_insn "" 12390 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 12391 (match_operand:SI 1 "general_operand" "r,m,r"))] 12392 "" 12393 "@ 12394 move %0,%1 12395 load %0,%1 12396 store %0,%1" 12397 [(set_attr "type" "arith,load,store")]) 12398 12399 Note that we assume in the above example that arithmetic operations 12400performed on quantities smaller than a machine word clobber the 12401condition code since they will set the condition code to a value 12402corresponding to the full-word result. 12403 12404 12405File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 12406 1240710.18.5 Computing the Length of an Insn 12408--------------------------------------- 12409 12410For many machines, multiple types of branch instructions are provided, 12411each for different length branch displacements. In most cases, the 12412assembler will choose the correct instruction to use. However, when 12413the assembler cannot do so, GCC can when a special attribute, the 12414`length' attribute, is defined. This attribute must be defined to have 12415numeric values by specifying a null string in its `define_attr'. 12416 12417 In the case of the `length' attribute, two additional forms of 12418arithmetic terms are allowed in test expressions: 12419 12420`(match_dup N)' 12421 This refers to the address of operand N of the current insn, which 12422 must be a `label_ref'. 12423 12424`(pc)' 12425 This refers to the address of the _current_ insn. It might have 12426 been more consistent with other usage to make this the address of 12427 the _next_ insn but this would be confusing because the length of 12428 the current insn is to be computed. 12429 12430 For normal insns, the length will be determined by value of the 12431`length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 12432patterns, the length is computed as the number of vectors multiplied by 12433the size of each vector. 12434 12435 Lengths are measured in addressable storage units (bytes). 12436 12437 The following macros can be used to refine the length computation: 12438 12439`ADJUST_INSN_LENGTH (INSN, LENGTH)' 12440 If defined, modifies the length assigned to instruction INSN as a 12441 function of the context in which it is used. LENGTH is an lvalue 12442 that contains the initially computed length of the insn and should 12443 be updated with the correct length of the insn. 12444 12445 This macro will normally not be required. A case in which it is 12446 required is the ROMP. On this machine, the size of an `addr_vec' 12447 insn must be increased by two to compensate for the fact that 12448 alignment may be required. 12449 12450 The routine that returns `get_attr_length' (the value of the 12451`length' attribute) can be used by the output routine to determine the 12452form of the branch instruction to be written, as the example below 12453illustrates. 12454 12455 As an example of the specification of variable-length branches, 12456consider the IBM 360. If we adopt the convention that a register will 12457be set to the starting address of a function, we can jump to labels 12458within 4k of the start using a four-byte instruction. Otherwise, we 12459need a six-byte sequence to load the address from memory and then 12460branch to it. 12461 12462 On such a machine, a pattern for a branch instruction might be 12463specified as follows: 12464 12465 (define_insn "jump" 12466 [(set (pc) 12467 (label_ref (match_operand 0 "" "")))] 12468 "" 12469 { 12470 return (get_attr_length (insn) == 4 12471 ? "b %l0" : "l r15,=a(%l0); br r15"); 12472 } 12473 [(set (attr "length") 12474 (if_then_else (lt (match_dup 0) (const_int 4096)) 12475 (const_int 4) 12476 (const_int 6)))]) 12477 12478 12479File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes 12480 1248110.18.6 Constant Attributes 12482--------------------------- 12483 12484A special form of `define_attr', where the expression for the default 12485value is a `const' expression, indicates an attribute that is constant 12486for a given run of the compiler. Constant attributes may be used to 12487specify which variety of processor is used. For example, 12488 12489 (define_attr "cpu" "m88100,m88110,m88000" 12490 (const 12491 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 12492 (symbol_ref "TARGET_88110") (const_string "m88110")] 12493 (const_string "m88000")))) 12494 12495 (define_attr "memory" "fast,slow" 12496 (const 12497 (if_then_else (symbol_ref "TARGET_FAST_MEM") 12498 (const_string "fast") 12499 (const_string "slow")))) 12500 12501 The routine generated for constant attributes has no parameters as it 12502does not depend on any particular insn. RTL expressions used to define 12503the value of a constant attribute may use the `symbol_ref' form, but 12504may not use either the `match_operand' form or `eq_attr' forms 12505involving insn attributes. 12506 12507 12508File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes 12509 1251010.18.7 Delay Slot Scheduling 12511----------------------------- 12512 12513The insn attribute mechanism can be used to specify the requirements for 12514delay slots, if any, on a target machine. An instruction is said to 12515require a "delay slot" if some instructions that are physically after 12516the instruction are executed as if they were located before it. 12517Classic examples are branch and call instructions, which often execute 12518the following instruction before the branch or call is performed. 12519 12520 On some machines, conditional branch instructions can optionally 12521"annul" instructions in the delay slot. This means that the 12522instruction will not be executed for certain branch outcomes. Both 12523instructions that annul if the branch is true and instructions that 12524annul if the branch is false are supported. 12525 12526 Delay slot scheduling differs from instruction scheduling in that 12527determining whether an instruction needs a delay slot is dependent only 12528on the type of instruction being generated, not on data flow between the 12529instructions. See the next section for a discussion of data-dependent 12530instruction scheduling. 12531 12532 The requirement of an insn needing one or more delay slots is 12533indicated via the `define_delay' expression. It has the following form: 12534 12535 (define_delay TEST 12536 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 12537 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 12538 ...]) 12539 12540 TEST is an attribute test that indicates whether this `define_delay' 12541applies to a particular insn. If so, the number of required delay 12542slots is determined by the length of the vector specified as the second 12543argument. An insn placed in delay slot N must satisfy attribute test 12544DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 12545may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 12546specifies which insns in the delay slot may be annulled if the branch 12547is false. If annulling is not supported for that delay slot, `(nil)' 12548should be coded. 12549 12550 For example, in the common case where branch and call insns require 12551a single delay slot, which may contain any insn other than a branch or 12552call, the following would be placed in the `md' file: 12553 12554 (define_delay (eq_attr "type" "branch,call") 12555 [(eq_attr "type" "!branch,call") (nil) (nil)]) 12556 12557 Multiple `define_delay' expressions may be specified. In this case, 12558each such expression specifies different delay slot requirements and 12559there must be no insn for which tests in two `define_delay' expressions 12560are both true. 12561 12562 For example, if we have a machine that requires one delay slot for 12563branches but two for calls, no delay slot can contain a branch or call 12564insn, and any valid insn in the delay slot for the branch can be 12565annulled if the branch is true, we might represent this as follows: 12566 12567 (define_delay (eq_attr "type" "branch") 12568 [(eq_attr "type" "!branch,call") 12569 (eq_attr "type" "!branch,call") 12570 (nil)]) 12571 12572 (define_delay (eq_attr "type" "call") 12573 [(eq_attr "type" "!branch,call") (nil) (nil) 12574 (eq_attr "type" "!branch,call") (nil) (nil)]) 12575 12576 12577File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 12578 1257910.18.8 Specifying processor pipeline description 12580------------------------------------------------- 12581 12582To achieve better performance, most modern processors (super-pipelined, 12583superscalar RISC, and VLIW processors) have many "functional units" on 12584which several instructions can be executed simultaneously. An 12585instruction starts execution if its issue conditions are satisfied. If 12586not, the instruction is stalled until its conditions are satisfied. 12587Such "interlock (pipeline) delay" causes interruption of the fetching 12588of successor instructions (or demands nop instructions, e.g. for some 12589MIPS processors). 12590 12591 There are two major kinds of interlock delays in modern processors. 12592The first one is a data dependence delay determining "instruction 12593latency time". The instruction execution is not started until all 12594source data have been evaluated by prior instructions (there are more 12595complex cases when the instruction execution starts even when the data 12596are not available but will be ready in given time after the instruction 12597execution start). Taking the data dependence delays into account is 12598simple. The data dependence (true, output, and anti-dependence) delay 12599between two instructions is given by a constant. In most cases this 12600approach is adequate. The second kind of interlock delays is a 12601reservation delay. The reservation delay means that two instructions 12602under execution will be in need of shared processors resources, i.e. 12603buses, internal registers, and/or functional units, which are reserved 12604for some time. Taking this kind of delay into account is complex 12605especially for modern RISC processors. 12606 12607 The task of exploiting more processor parallelism is solved by an 12608instruction scheduler. For a better solution to this problem, the 12609instruction scheduler has to have an adequate description of the 12610processor parallelism (or "pipeline description"). Currently GCC 12611provides two alternative ways to describe processor parallelism, both 12612described below. The first method is outlined in the next section; it 12613was once the only method provided by GCC, and thus is used in a number 12614of exiting ports. The second, and preferred method, specifies 12615functional unit reservations for groups of instructions with the aid of 12616"regular expressions". This is called the "automaton based 12617description". 12618 12619 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 12620figure out the possibility of the instruction issue by the processor on 12621a given simulated processor cycle. The pipeline hazard recognizer is 12622automatically generated from the processor pipeline description. The 12623pipeline hazard recognizer generated from the automaton based 12624description is more sophisticated and based on a deterministic finite 12625state automaton (DFA) and therefore faster than one generated from the 12626old description. Furthermore, its speed is not dependent on processor 12627complexity. The instruction issue is possible if there is a transition 12628from one automaton state to another one. 12629 12630 You can use either model to describe processor pipeline 12631characteristics or even mix them. You could use the old description 12632for some processor submodels and the DFA-based one for other processor 12633submodels. 12634 12635 In general, using the automaton based description is preferred. Its 12636model is richer and makes it possible to more accurately describe 12637pipeline characteristics of processors, which results in improved code 12638quality (although sometimes only marginally). It will also be used as 12639an infrastructure to implement sophisticated and practical instruction 12640scheduling which will try many instruction sequences to choose the best 12641one. 12642 12643* Menu: 12644 12645* Old pipeline description:: Specifying information for insn scheduling. 12646* Automaton pipeline description:: Describing insn pipeline characteristics. 12647* Comparison of the two descriptions:: Drawbacks of the old pipeline description 12648 12649 12650File: gccint.info, Node: Old pipeline description, Next: Automaton pipeline description, Up: Processor pipeline description 12651 1265210.18.8.1 Specifying Function Units 12653................................... 12654 12655On most RISC machines, there are instructions whose results are not 12656available for a specific number of cycles. Common cases are 12657instructions that load data from memory. On many machines, a pipeline 12658stall will result if the data is referenced too soon after the load 12659instruction. 12660 12661 In addition, many newer microprocessors have multiple function 12662units, usually one for integer and one for floating point, and often 12663will incur pipeline stalls when a result that is needed is not yet 12664ready. 12665 12666 The descriptions in this section allow the specification of how much 12667time must elapse between the execution of an instruction and the time 12668when its result is used. It also allows specification of when the 12669execution of an instruction will delay execution of similar instructions 12670due to function unit conflicts. 12671 12672 For the purposes of the specifications in this section, a machine is 12673divided into "function units", each of which execute a specific class 12674of instructions in first-in-first-out order. Function units that 12675accept one instruction each cycle and allow a result to be used in the 12676succeeding instruction (usually via forwarding) need not be specified. 12677Classic RISC microprocessors will normally have a single function unit, 12678which we can call `memory'. The newer "superscalar" processors will 12679often have function units for floating point operations, usually at 12680least a floating point adder and multiplier. 12681 12682 Each usage of a function units by a class of insns is specified with 12683a `define_function_unit' expression, which looks like this: 12684 12685 (define_function_unit NAME MULTIPLICITY SIMULTANEITY 12686 TEST READY-DELAY ISSUE-DELAY 12687 [CONFLICT-LIST]) 12688 12689 NAME is a string giving the name of the function unit. 12690 12691 MULTIPLICITY is an integer specifying the number of identical units 12692in the processor. If more than one unit is specified, they will be 12693scheduled independently. Only truly independent units should be 12694counted; a pipelined unit should be specified as a single unit. (The 12695only common example of a machine that has multiple function units for a 12696single instruction class that are truly independent and not pipelined 12697are the two multiply and two increment units of the CDC 6600.) 12698 12699 SIMULTANEITY specifies the maximum number of insns that can be 12700executing in each instance of the function unit simultaneously or zero 12701if the unit is pipelined and has no limit. 12702 12703 All `define_function_unit' definitions referring to function unit 12704NAME must have the same name and values for MULTIPLICITY and 12705SIMULTANEITY. 12706 12707 TEST is an attribute test that selects the insns we are describing 12708in this definition. Note that an insn may use more than one function 12709unit and a function unit may be specified in more than one 12710`define_function_unit'. 12711 12712 READY-DELAY is an integer that specifies the number of cycles after 12713which the result of the instruction can be used without introducing any 12714stalls. 12715 12716 ISSUE-DELAY is an integer that specifies the number of cycles after 12717the instruction matching the TEST expression begins using this unit 12718until a subsequent instruction can begin. A cost of N indicates an N-1 12719cycle delay. A subsequent instruction may also be delayed if an 12720earlier instruction has a longer READY-DELAY value. This blocking 12721effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY, 12722and CONFLICT-LIST terms. For a normal non-pipelined function unit, 12723SIMULTANEITY is one, the unit is taken to block for the READY-DELAY 12724cycles of the executing insn, and smaller values of ISSUE-DELAY are 12725ignored. 12726 12727 CONFLICT-LIST is an optional list giving detailed conflict costs for 12728this unit. If specified, it is a list of condition test expressions to 12729be applied to insns chosen to execute in NAME following the particular 12730insn matching TEST that is already executing in NAME. For each insn in 12731the list, ISSUE-DELAY specifies the conflict cost; for insns not in the 12732list, the cost is zero. If not specified, CONFLICT-LIST defaults to 12733all instructions that use the function unit. 12734 12735 Typical uses of this vector are where a floating point function unit 12736can pipeline either single- or double-precision operations, but not 12737both, or where a memory unit can pipeline loads, but not stores, etc. 12738 12739 As an example, consider a classic RISC machine where the result of a 12740load instruction is not available for two cycles (a single "delay" 12741instruction is required) and where only one load instruction can be 12742executed simultaneously. This would be specified as: 12743 12744 (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0) 12745 12746 For the case of a floating point function unit that can pipeline 12747either single or double precision, but not both, the following could be 12748specified: 12749 12750 (define_function_unit 12751 "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")]) 12752 (define_function_unit 12753 "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")]) 12754 12755 *Note:* The scheduler attempts to avoid function unit conflicts and 12756uses all the specifications in the `define_function_unit' expression. 12757It has recently been discovered that these specifications may not allow 12758modeling of some of the newer "superscalar" processors that have insns 12759using multiple pipelined units. These insns will cause a potential 12760conflict for the second unit used during their execution and there is 12761no way of representing that conflict. Any examples of how function 12762unit conflicts work in such processors and suggestions for their 12763representation would be welcomed. 12764 12765 12766File: gccint.info, Node: Automaton pipeline description, Next: Comparison of the two descriptions, Prev: Old pipeline description, Up: Processor pipeline description 12767 1276810.18.8.2 Describing instruction pipeline characteristics 12769......................................................... 12770 12771This section describes constructions of the automaton based processor 12772pipeline description. The order of constructions within the machine 12773description file is not important. 12774 12775 The following optional construction describes names of automata 12776generated and used for the pipeline hazards recognition. Sometimes the 12777generated finite state automaton used by the pipeline hazard recognizer 12778is large. If we use more than one automaton and bind functional units 12779to the automata, the total size of the automata is usually less than 12780the size of the single automaton. If there is no one such 12781construction, only one finite state automaton is generated. 12782 12783 (define_automaton AUTOMATA-NAMES) 12784 12785 AUTOMATA-NAMES is a string giving names of the automata. The names 12786are separated by commas. All the automata should have unique names. 12787The automaton name is used in the constructions `define_cpu_unit' and 12788`define_query_cpu_unit'. 12789 12790 Each processor functional unit used in the description of instruction 12791reservations should be described by the following construction. 12792 12793 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 12794 12795 UNIT-NAMES is a string giving the names of the functional units 12796separated by commas. Don't use name `nothing', it is reserved for 12797other goals. 12798 12799 AUTOMATON-NAME is a string giving the name of the automaton with 12800which the unit is bound. The automaton should be described in 12801construction `define_automaton'. You should give "automaton-name", if 12802there is a defined automaton. 12803 12804 The assignment of units to automata are constrained by the uses of 12805the units in insn reservations. The most important constraint is: if a 12806unit reservation is present on a particular cycle of an alternative for 12807an insn reservation, then some unit from the same automaton must be 12808present on the same cycle for the other alternatives of the insn 12809reservation. The rest of the constraints are mentioned in the 12810description of the subsequent constructions. 12811 12812 The following construction describes CPU functional units analogously 12813to `define_cpu_unit'. The reservation of such units can be queried for 12814an automaton state. The instruction scheduler never queries 12815reservation of functional units for given automaton state. So as a 12816rule, you don't need this construction. This construction could be 12817used for future code generation goals (e.g. to generate VLIW insn 12818templates). 12819 12820 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 12821 12822 UNIT-NAMES is a string giving names of the functional units 12823separated by commas. 12824 12825 AUTOMATON-NAME is a string giving the name of the automaton with 12826which the unit is bound. 12827 12828 The following construction is the major one to describe pipeline 12829characteristics of an instruction. 12830 12831 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 12832 CONDITION REGEXP) 12833 12834 DEFAULT_LATENCY is a number giving latency time of the instruction. 12835There is an important difference between the old description and the 12836automaton based pipeline description. The latency time is used for all 12837dependencies when we use the old description. In the automaton based 12838pipeline description, the given latency time is only used for true 12839dependencies. The cost of anti-dependencies is always zero and the 12840cost of output dependencies is the difference between latency times of 12841the producing and consuming insns (if the difference is negative, the 12842cost is considered to be zero). You can always change the default 12843costs for any description by using the target hook 12844`TARGET_SCHED_ADJUST_COST' (*note Scheduling::). 12845 12846 INSN-NAME is a string giving the internal name of the insn. The 12847internal names are used in constructions `define_bypass' and in the 12848automaton description file generated for debugging. The internal name 12849has nothing in common with the names in `define_insn'. It is a good 12850practice to use insn classes described in the processor manual. 12851 12852 CONDITION defines what RTL insns are described by this construction. 12853You should remember that you will be in trouble if CONDITION for two 12854or more different `define_insn_reservation' constructions is TRUE for 12855an insn. In this case what reservation will be used for the insn is 12856not defined. Such cases are not checked during generation of the 12857pipeline hazards recognizer because in general recognizing that two 12858conditions may have the same value is quite difficult (especially if 12859the conditions contain `symbol_ref'). It is also not checked during the 12860pipeline hazard recognizer work because it would slow down the 12861recognizer considerably. 12862 12863 REGEXP is a string describing the reservation of the cpu's functional 12864units by the instruction. The reservations are described by a regular 12865expression according to the following syntax: 12866 12867 regexp = regexp "," oneof 12868 | oneof 12869 12870 oneof = oneof "|" allof 12871 | allof 12872 12873 allof = allof "+" repeat 12874 | repeat 12875 12876 repeat = element "*" number 12877 | element 12878 12879 element = cpu_function_unit_name 12880 | reservation_name 12881 | result_name 12882 | "nothing" 12883 | "(" regexp ")" 12884 12885 * `,' is used for describing the start of the next cycle in the 12886 reservation. 12887 12888 * `|' is used for describing a reservation described by the first 12889 regular expression *or* a reservation described by the second 12890 regular expression *or* etc. 12891 12892 * `+' is used for describing a reservation described by the first 12893 regular expression *and* a reservation described by the second 12894 regular expression *and* etc. 12895 12896 * `*' is used for convenience and simply means a sequence in which 12897 the regular expression are repeated NUMBER times with cycle 12898 advancing (see `,'). 12899 12900 * `cpu_function_unit_name' denotes reservation of the named 12901 functional unit. 12902 12903 * `reservation_name' -- see description of construction 12904 `define_reservation'. 12905 12906 * `nothing' denotes no unit reservations. 12907 12908 Sometimes unit reservations for different insns contain common parts. 12909In such case, you can simplify the pipeline description by describing 12910the common part by the following construction 12911 12912 (define_reservation RESERVATION-NAME REGEXP) 12913 12914 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 12915names and reservation names are in the same name space. So the 12916reservation names should be different from the functional unit names 12917and can not be the reserved name `nothing'. 12918 12919 The following construction is used to describe exceptions in the 12920latency time for given instruction pair. This is so called bypasses. 12921 12922 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 12923 [GUARD]) 12924 12925 NUMBER defines when the result generated by the instructions given 12926in string OUT_INSN_NAMES will be ready for the instructions given in 12927string IN_INSN_NAMES. The instructions in the string are separated by 12928commas. 12929 12930 GUARD is an optional string giving the name of a C function which 12931defines an additional guard for the bypass. The function will get the 12932two insns as parameters. If the function returns zero the bypass will 12933be ignored for this case. The additional guard is necessary to 12934recognize complicated bypasses, e.g. when the consumer is only an 12935address of insn `store' (not a stored value). 12936 12937 The following five constructions are usually used to describe VLIW 12938processors, or more precisely, to describe a placement of small 12939instructions into VLIW instruction slots. They can be used for RISC 12940processors, too. 12941 12942 (exclusion_set UNIT-NAMES UNIT-NAMES) 12943 (presence_set UNIT-NAMES PATTERNS) 12944 (final_presence_set UNIT-NAMES PATTERNS) 12945 (absence_set UNIT-NAMES PATTERNS) 12946 (final_absence_set UNIT-NAMES PATTERNS) 12947 12948 UNIT-NAMES is a string giving names of functional units separated by 12949commas. 12950 12951 PATTERNS is a string giving patterns of functional units separated 12952by comma. Currently pattern is is one unit or units separated by 12953white-spaces. 12954 12955 The first construction (`exclusion_set') means that each functional 12956unit in the first string can not be reserved simultaneously with a unit 12957whose name is in the second string and vice versa. For example, the 12958construction is useful for describing processors (e.g. some SPARC 12959processors) with a fully pipelined floating point functional unit which 12960can execute simultaneously only single floating point insns or only 12961double floating point insns. 12962 12963 The second construction (`presence_set') means that each functional 12964unit in the first string can not be reserved unless at least one of 12965pattern of units whose names are in the second string is reserved. 12966This is an asymmetric relation. For example, it is useful for 12967description that VLIW `slot1' is reserved after `slot0' reservation. 12968We could describe it by the following construction 12969 12970 (presence_set "slot1" "slot0") 12971 12972 Or `slot1' is reserved only after `slot0' and unit `b0' reservation. 12973In this case we could write 12974 12975 (presence_set "slot1" "slot0 b0") 12976 12977 The third construction (`final_presence_set') is analogous to 12978`presence_set'. The difference between them is when checking is done. 12979When an instruction is issued in given automaton state reflecting all 12980current and planned unit reservations, the automaton state is changed. 12981The first state is a source state, the second one is a result state. 12982Checking for `presence_set' is done on the source state reservation, 12983checking for `final_presence_set' is done on the result reservation. 12984This construction is useful to describe a reservation which is actually 12985two subsequent reservations. For example, if we use 12986 12987 (presence_set "slot1" "slot0") 12988 12989 the following insn will be never issued (because `slot1' requires 12990`slot0' which is absent in the source state). 12991 12992 (define_reservation "insn_and_nop" "slot0 + slot1") 12993 12994 but it can be issued if we use analogous `final_presence_set'. 12995 12996 The forth construction (`absence_set') means that each functional 12997unit in the first string can be reserved only if each pattern of units 12998whose names are in the second string is not reserved. This is an 12999asymmetric relation (actually `exclusion_set' is analogous to this one 13000but it is symmetric). For example, it is useful for description that 13001VLIW `slot0' can not be reserved after `slot1' or `slot2' reservation. 13002We could describe it by the following construction 13003 13004 (absence_set "slot2" "slot0, slot1") 13005 13006 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved 13007or `slot1' and unit `b1' are reserved. In this case we could write 13008 13009 (absence_set "slot2" "slot0 b0, slot1 b1") 13010 13011 All functional units mentioned in a set should belong to the same 13012automaton. 13013 13014 The last construction (`final_absence_set') is analogous to 13015`absence_set' but checking is done on the result (state) reservation. 13016See comments for `final_presence_set'. 13017 13018 You can control the generator of the pipeline hazard recognizer with 13019the following construction. 13020 13021 (automata_option OPTIONS) 13022 13023 OPTIONS is a string giving options which affect the generated code. 13024Currently there are the following options: 13025 13026 * "no-minimization" makes no minimization of the automaton. This is 13027 only worth to do when we are debugging the description and need to 13028 look more accurately at reservations of states. 13029 13030 * "time" means printing additional time statistics about generation 13031 of automata. 13032 13033 * "v" means a generation of the file describing the result automata. 13034 The file has suffix `.dfa' and can be used for the description 13035 verification and debugging. 13036 13037 * "w" means a generation of warning instead of error for 13038 non-critical errors. 13039 13040 * "ndfa" makes nondeterministic finite state automata. This affects 13041 the treatment of operator `|' in the regular expressions. The 13042 usual treatment of the operator is to try the first alternative 13043 and, if the reservation is not possible, the second alternative. 13044 The nondeterministic treatment means trying all alternatives, some 13045 of them may be rejected by reservations in the subsequent insns. 13046 You can not query functional unit reservations in nondeterministic 13047 automaton states. 13048 13049 * "progress" means output of a progress bar showing how many states 13050 were generated so far for automaton being processed. This is 13051 useful during debugging a DFA description. If you see too many 13052 generated states, you could interrupt the generator of the pipeline 13053 hazard recognizer and try to figure out a reason for generation of 13054 the huge automaton. 13055 13056 As an example, consider a superscalar RISC machine which can issue 13057three insns (two integer insns and one floating point insn) on the 13058cycle but can finish only two insns. To describe this, we define the 13059following functional units. 13060 13061 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 13062 (define_cpu_unit "port0, port1") 13063 13064 All simple integer insns can be executed in any integer pipeline and 13065their result is ready in two cycles. The simple integer insns are 13066issued into the first pipeline unless it is reserved, otherwise they 13067are issued into the second pipeline. Integer division and 13068multiplication insns can be executed only in the second integer 13069pipeline and their results are ready correspondingly in 8 and 4 cycles. 13070The integer division is not pipelined, i.e. the subsequent integer 13071division insn can not be issued until the current division insn 13072finished. Floating point insns are fully pipelined and their results 13073are ready in 3 cycles. Where the result of a floating point insn is 13074used by an integer insn, an additional delay of one cycle is incurred. 13075To describe all of this we could specify 13076 13077 (define_cpu_unit "div") 13078 13079 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 13080 "(i0_pipeline | i1_pipeline), (port0 | port1)") 13081 13082 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 13083 "i1_pipeline, nothing*2, (port0 | port1)") 13084 13085 (define_insn_reservation "div" 8 (eq_attr "type" "div") 13086 "i1_pipeline, div*7, div + (port0 | port1)") 13087 13088 (define_insn_reservation "float" 3 (eq_attr "type" "float") 13089 "f_pipeline, nothing, (port0 | port1)) 13090 13091 (define_bypass 4 "float" "simple,mult,div") 13092 13093 To simplify the description we could describe the following 13094reservation 13095 13096 (define_reservation "finish" "port0|port1") 13097 13098 and use it in all `define_insn_reservation' as in the following 13099construction 13100 13101 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 13102 "(i0_pipeline | i1_pipeline), finish") 13103 13104 13105File: gccint.info, Node: Comparison of the two descriptions, Prev: Automaton pipeline description, Up: Processor pipeline description 13106 1310710.18.8.3 Drawbacks of the old pipeline description 13108................................................... 13109 13110The old instruction level parallelism description and the pipeline 13111hazards recognizer based on it have the following drawbacks in 13112comparison with the DFA-based ones: 13113 13114 * Each functional unit is believed to be reserved at the instruction 13115 execution start. This is a very inaccurate model for modern 13116 processors. 13117 13118 * An inadequate description of instruction latency times. The 13119 latency time is bound with a functional unit reserved by an 13120 instruction not with the instruction itself. In other words, the 13121 description is oriented to describe at most one unit reservation 13122 by each instruction. It also does not permit to describe special 13123 bypasses between instruction pairs. 13124 13125 * The implementation of the pipeline hazard recognizer interface has 13126 constraints on number of functional units. This is a number of 13127 bits in integer on the host machine. 13128 13129 * The interface to the pipeline hazard recognizer is more complex 13130 than one to the automaton based pipeline recognizer. 13131 13132 * An unnatural description when you write a unit and a condition 13133 which selects instructions using the unit. Writing all unit 13134 reservations for an instruction (an instruction class) is more 13135 natural. 13136 13137 * The recognition of the interlock delays has a slow implementation. 13138 The GCC scheduler supports structures which describe the unit 13139 reservations. The more functional units a processor has, the 13140 slower its pipeline hazard recognizer will be. Such an 13141 implementation would become even slower when we allowed to reserve 13142 functional units not only at the instruction execution start. In 13143 an automaton based pipeline hazard recognizer, speed is not 13144 dependent on processor complexity. 13145 13146 13147File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc 13148 1314910.19 Conditional Execution 13150=========================== 13151 13152A number of architectures provide for some form of conditional 13153execution, or predication. The hallmark of this feature is the ability 13154to nullify most of the instructions in the instruction set. When the 13155instruction set is large and not entirely symmetric, it can be quite 13156tedious to describe these forms directly in the `.md' file. An 13157alternative is the `define_cond_exec' template. 13158 13159 (define_cond_exec 13160 [PREDICATE-PATTERN] 13161 "CONDITION" 13162 "OUTPUT-TEMPLATE") 13163 13164 PREDICATE-PATTERN is the condition that must be true for the insn to 13165be executed at runtime and should match a relational operator. One can 13166use `match_operator' to match several relational operators at once. 13167Any `match_operand' operands must have no more than one alternative. 13168 13169 CONDITION is a C expression that must be true for the generated 13170pattern to match. 13171 13172 OUTPUT-TEMPLATE is a string similar to the `define_insn' output 13173template (*note Output Template::), except that the `*' and `@' special 13174cases do not apply. This is only useful if the assembly text for the 13175predicate is a simple prefix to the main insn. In order to handle the 13176general case, there is a global variable `current_insn_predicate' that 13177will contain the entire predicate if the current insn is predicated, 13178and will otherwise be `NULL'. 13179 13180 When `define_cond_exec' is used, an implicit reference to the 13181`predicable' instruction attribute is made. *Note Insn Attributes::. 13182This attribute must be boolean (i.e. have exactly two elements in its 13183LIST-OF-VALUES). Further, it must not be used with complex 13184expressions. That is, the default and all uses in the insns must be a 13185simple constant, not dependent on the alternative or anything else. 13186 13187 For each `define_insn' for which the `predicable' attribute is true, 13188a new `define_insn' pattern will be generated that matches a predicated 13189version of the instruction. For example, 13190 13191 (define_insn "addsi" 13192 [(set (match_operand:SI 0 "register_operand" "r") 13193 (plus:SI (match_operand:SI 1 "register_operand" "r") 13194 (match_operand:SI 2 "register_operand" "r")))] 13195 "TEST1" 13196 "add %2,%1,%0") 13197 13198 (define_cond_exec 13199 [(ne (match_operand:CC 0 "register_operand" "c") 13200 (const_int 0))] 13201 "TEST2" 13202 "(%0)") 13203 13204generates a new pattern 13205 13206 (define_insn "" 13207 [(cond_exec 13208 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 13209 (set (match_operand:SI 0 "register_operand" "r") 13210 (plus:SI (match_operand:SI 1 "register_operand" "r") 13211 (match_operand:SI 2 "register_operand" "r"))))] 13212 "(TEST2) && (TEST1)" 13213 "(%3) add %2,%1,%0") 13214 13215 13216File: gccint.info, Node: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 13217 1321810.20 Constant Definitions 13219========================== 13220 13221Using literal constants inside instruction patterns reduces legibility 13222and can be a maintenance problem. 13223 13224 To overcome this problem, you may use the `define_constants' 13225expression. It contains a vector of name-value pairs. From that point 13226on, wherever any of the names appears in the MD file, it is as if the 13227corresponding value had been written instead. You may use 13228`define_constants' multiple times; each appearance adds more constants 13229to the table. It is an error to redefine a constant with a different 13230value. 13231 13232 To come back to the a29k load multiple example, instead of 13233 13234 (define_insn "" 13235 [(match_parallel 0 "load_multiple_operation" 13236 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 13237 (match_operand:SI 2 "memory_operand" "m")) 13238 (use (reg:SI 179)) 13239 (clobber (reg:SI 179))])] 13240 "" 13241 "loadm 0,0,%1,%2") 13242 13243 You could write: 13244 13245 (define_constants [ 13246 (R_BP 177) 13247 (R_FC 178) 13248 (R_CR 179) 13249 (R_Q 180) 13250 ]) 13251 13252 (define_insn "" 13253 [(match_parallel 0 "load_multiple_operation" 13254 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 13255 (match_operand:SI 2 "memory_operand" "m")) 13256 (use (reg:SI R_CR)) 13257 (clobber (reg:SI R_CR))])] 13258 "" 13259 "loadm 0,0,%1,%2") 13260 13261 The constants that are defined with a define_constant are also output 13262in the insn-codes.h header file as #defines. 13263 13264 13265File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 13266 1326711 Target Description Macros and Functions 13268****************************************** 13269 13270In addition to the file `MACHINE.md', a machine description includes a 13271C header file conventionally given the name `MACHINE.h' and a C source 13272file named `MACHINE.c'. The header file defines numerous macros that 13273convey the information about the target machine that does not fit into 13274the scheme of the `.md' file. The file `tm.h' should be a link to 13275`MACHINE.h'. The header file `config.h' includes `tm.h' and most 13276compiler source files include `config.h'. The source file defines a 13277variable `targetm', which is a structure containing pointers to 13278functions and data relating to the target machine. `MACHINE.c' should 13279also contain their definitions, if they are not defined elsewhere in 13280GCC, and other functions called through the macros defined in the `.h' 13281file. 13282 13283* Menu: 13284 13285* Target Structure:: The `targetm' variable. 13286* Driver:: Controlling how the driver runs the compilation passes. 13287* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 13288* Per-Function Data:: Defining data structures for per-function information. 13289* Storage Layout:: Defining sizes and alignments of data. 13290* Type Layout:: Defining sizes and properties of basic user data types. 13291* Escape Sequences:: Defining the value of target character escape sequences 13292* Registers:: Naming and describing the hardware registers. 13293* Register Classes:: Defining the classes of hardware registers. 13294* Stack and Calling:: Defining which way the stack grows and by how much. 13295* Varargs:: Defining the varargs macros. 13296* Trampolines:: Code set up at run time to enter a nested function. 13297* Library Calls:: Controlling how library routines are implicitly called. 13298* Addressing Modes:: Defining addressing modes valid for memory operands. 13299* Condition Code:: Defining how insns update the condition code. 13300* Costs:: Defining relative costs of different operations. 13301* Scheduling:: Adjusting the behavior of the instruction scheduler. 13302* Sections:: Dividing storage into text, data, and other sections. 13303* PIC:: Macros for position independent code. 13304* Assembler Format:: Defining how to write insns and pseudo-ops to output. 13305* Debugging Info:: Defining the format of debugging output. 13306* Floating Point:: Handling floating point for cross-compilers. 13307* Mode Switching:: Insertion of mode-switching instructions. 13308* Target Attributes:: Defining target-specific uses of `__attribute__'. 13309* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 13310* PCH Target:: Validity checking for precompiled headers. 13311* Misc:: Everything else. 13312 13313 13314File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 13315 1331611.1 The Global `targetm' Variable 13317================================== 13318 13319 -- Variable: struct gcc_target targetm 13320 The target `.c' file must define the global `targetm' variable 13321 which contains pointers to functions and data relating to the 13322 target machine. The variable is declared in `target.h'; 13323 `target-def.h' defines the macro `TARGET_INITIALIZER' which is 13324 used to initialize the variable, and macros for the default 13325 initializers for elements of the structure. The `.c' file should 13326 override those macros for which the default definition is 13327 inappropriate. For example: 13328 #include "target.h" 13329 #include "target-def.h" 13330 13331 /* Initialize the GCC target structure. */ 13332 13333 #undef TARGET_COMP_TYPE_ATTRIBUTES 13334 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 13335 13336 struct gcc_target targetm = TARGET_INITIALIZER; 13337 13338Where a macro should be defined in the `.c' file in this manner to form 13339part of the `targetm' structure, it is documented below as a "Target 13340Hook" with a prototype. Many macros will change in future from being 13341defined in the `.h' file to being part of the `targetm' structure. 13342 13343 13344File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 13345 1334611.2 Controlling the Compilation Driver, `gcc' 13347============================================== 13348 13349You can control the compilation driver. 13350 13351 -- Macro: SWITCH_TAKES_ARG (CHAR) 13352 A C expression which determines whether the option `-CHAR' takes 13353 arguments. The value should be the number of arguments that 13354 option takes-zero, for many options. 13355 13356 By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG', 13357 which handles the standard options properly. You need not define 13358 `SWITCH_TAKES_ARG' unless you wish to add additional options which 13359 take arguments. Any redefinition should call 13360 `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options. 13361 13362 -- Macro: WORD_SWITCH_TAKES_ARG (NAME) 13363 A C expression which determines whether the option `-NAME' takes 13364 arguments. The value should be the number of arguments that 13365 option takes-zero, for many options. This macro rather than 13366 `SWITCH_TAKES_ARG' is used for multi-character option names. 13367 13368 By default, this macro is defined as 13369 `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options 13370 properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you 13371 wish to add additional options which take arguments. Any 13372 redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then 13373 check for additional options. 13374 13375 -- Macro: SWITCH_CURTAILS_COMPILATION (CHAR) 13376 A C expression which determines whether the option `-CHAR' stops 13377 compilation before the generation of an executable. The value is 13378 boolean, nonzero if the option does stop an executable from being 13379 generated, zero otherwise. 13380 13381 By default, this macro is defined as 13382 `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard 13383 options properly. You need not define 13384 `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional 13385 options which affect the generation of an executable. Any 13386 redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and 13387 then check for additional options. 13388 13389 -- Macro: SWITCHES_NEED_SPACES 13390 A string-valued C expression which enumerates the options for which 13391 the linker needs a space between the option and its argument. 13392 13393 If this macro is not defined, the default value is `""'. 13394 13395 -- Macro: TARGET_OPTION_TRANSLATE_TABLE 13396 If defined, a list of pairs of strings, the first of which is a 13397 potential command line target to the `gcc' driver program, and the 13398 second of which is a space-separated (tabs and other whitespace 13399 are not supported) list of options with which to replace the first 13400 option. The target defining this list is responsible for assuring 13401 that the results are valid. Replacement options may not be the 13402 `--opt' style, they must be the `-opt' style. It is the intention 13403 of this macro to provide a mechanism for substitution that affects 13404 the multilibs chosen, such as one option that enables many 13405 options, some of which select multilibs. Example nonsensical 13406 definition, where `-malt-abi', `-EB', and `-mspoo' cause different 13407 multilibs to be chosen: 13408 13409 #define TARGET_OPTION_TRANSLATE_TABLE \ 13410 { "-fast", "-march=fast-foo -malt-abi -I/usr/fast-foo" }, \ 13411 { "-compat", "-EB -malign=4 -mspoo" } 13412 13413 -- Macro: DRIVER_SELF_SPECS 13414 A list of specs for the driver itself. It should be a suitable 13415 initializer for an array of strings, with no surrounding braces. 13416 13417 The driver applies these specs to its own command line between 13418 loading default `specs' files (but not command-line specified 13419 ones) and choosing the multilib directory or running any 13420 subcommands. It applies them in the order given, so each spec can 13421 depend on the options added by earlier ones. It is also possible 13422 to remove options using `%<OPTION' in the usual way. 13423 13424 This macro can be useful when a port has several interdependent 13425 target options. It provides a way of standardizing the command 13426 line so that the other specs are easier to write. 13427 13428 Do not define this macro if it does not need to do anything. 13429 13430 -- Macro: OPTION_DEFAULT_SPECS 13431 A list of specs used to support configure-time default options 13432 (i.e. `--with' options) in the driver. It should be a suitable 13433 initializer for an array of structures, each containing two 13434 strings, without the outermost pair of surrounding braces. 13435 13436 The first item in the pair is the name of the default. This must 13437 match the code in `config.gcc' for the target. The second item is 13438 a spec to apply if a default with this name was specified. The 13439 string `%(VALUE)' in the spec will be replaced by the value of the 13440 default everywhere it occurs. 13441 13442 The driver will apply these specs to its own command line between 13443 loading default `specs' files and processing `DRIVER_SELF_SPECS', 13444 using the same mechanism as `DRIVER_SELF_SPECS'. 13445 13446 Do not define this macro if it does not need to do anything. 13447 13448 -- Macro: CPP_SPEC 13449 A C string constant that tells the GCC driver program options to 13450 pass to CPP. It can also specify how to translate options you 13451 give to GCC into options for GCC to pass to the CPP. 13452 13453 Do not define this macro if it does not need to do anything. 13454 13455 -- Macro: CPLUSPLUS_CPP_SPEC 13456 This macro is just like `CPP_SPEC', but is used for C++, rather 13457 than C. If you do not define this macro, then the value of 13458 `CPP_SPEC' (if any) will be used instead. 13459 13460 -- Macro: CC1_SPEC 13461 A C string constant that tells the GCC driver program options to 13462 pass to `cc1', `cc1plus', `f771', and the other language front 13463 ends. It can also specify how to translate options you give to 13464 GCC into options for GCC to pass to front ends. 13465 13466 Do not define this macro if it does not need to do anything. 13467 13468 -- Macro: CC1PLUS_SPEC 13469 A C string constant that tells the GCC driver program options to 13470 pass to `cc1plus'. It can also specify how to translate options 13471 you give to GCC into options for GCC to pass to the `cc1plus'. 13472 13473 Do not define this macro if it does not need to do anything. Note 13474 that everything defined in CC1_SPEC is already passed to `cc1plus' 13475 so there is no need to duplicate the contents of CC1_SPEC in 13476 CC1PLUS_SPEC. 13477 13478 -- Macro: ASM_SPEC 13479 A C string constant that tells the GCC driver program options to 13480 pass to the assembler. It can also specify how to translate 13481 options you give to GCC into options for GCC to pass to the 13482 assembler. See the file `sun3.h' for an example of this. 13483 13484 Do not define this macro if it does not need to do anything. 13485 13486 -- Macro: ASM_FINAL_SPEC 13487 A C string constant that tells the GCC driver program how to run 13488 any programs which cleanup after the normal assembler. Normally, 13489 this is not needed. See the file `mips.h' for an example of this. 13490 13491 Do not define this macro if it does not need to do anything. 13492 13493 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 13494 Define this macro, with no value, if the driver should give the 13495 assembler an argument consisting of a single dash, `-', to 13496 instruct it to read from its standard input (which will be a pipe 13497 connected to the output of the compiler proper). This argument is 13498 given after any `-o' option specifying the name of the output file. 13499 13500 If you do not define this macro, the assembler is assumed to read 13501 its standard input if given no non-option arguments. If your 13502 assembler cannot read standard input at all, use a `%{pipe:%e}' 13503 construct; see `mips.h' for instance. 13504 13505 -- Macro: LINK_SPEC 13506 A C string constant that tells the GCC driver program options to 13507 pass to the linker. It can also specify how to translate options 13508 you give to GCC into options for GCC to pass to the linker. 13509 13510 Do not define this macro if it does not need to do anything. 13511 13512 -- Macro: LIB_SPEC 13513 Another C string constant used much like `LINK_SPEC'. The 13514 difference between the two is that `LIB_SPEC' is used at the end 13515 of the command given to the linker. 13516 13517 If this macro is not defined, a default is provided that loads the 13518 standard C library from the usual place. See `gcc.c'. 13519 13520 -- Macro: LIBGCC_SPEC 13521 Another C string constant that tells the GCC driver program how 13522 and when to place a reference to `libgcc.a' into the linker 13523 command line. This constant is placed both before and after the 13524 value of `LIB_SPEC'. 13525 13526 If this macro is not defined, the GCC driver provides a default 13527 that passes the string `-lgcc' to the linker. 13528 13529 -- Macro: STARTFILE_SPEC 13530 Another C string constant used much like `LINK_SPEC'. The 13531 difference between the two is that `STARTFILE_SPEC' is used at the 13532 very beginning of the command given to the linker. 13533 13534 If this macro is not defined, a default is provided that loads the 13535 standard C startup file from the usual place. See `gcc.c'. 13536 13537 -- Macro: ENDFILE_SPEC 13538 Another C string constant used much like `LINK_SPEC'. The 13539 difference between the two is that `ENDFILE_SPEC' is used at the 13540 very end of the command given to the linker. 13541 13542 Do not define this macro if it does not need to do anything. 13543 13544 -- Macro: THREAD_MODEL_SPEC 13545 GCC `-v' will print the thread model GCC was configured to use. 13546 However, this doesn't work on platforms that are multilibbed on 13547 thread models, such as AIX 4.3. On such platforms, define 13548 `THREAD_MODEL_SPEC' such that it evaluates to a string without 13549 blanks that names one of the recognized thread models. `%*', the 13550 default value of this macro, will expand to the value of 13551 `thread_file' set in `config.gcc'. 13552 13553 -- Macro: SYSROOT_SUFFIX_SPEC 13554 Define this macro to add a suffix to the target sysroot when GCC is 13555 configured with a sysroot. This will cause GCC to search for 13556 usr/lib, et al, within sysroot+suffix. 13557 13558 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 13559 Define this macro to add a headers_suffix to the target sysroot 13560 when GCC is configured with a sysroot. This will cause GCC to 13561 pass the updated sysroot+headers_suffix to CPP, causing it to 13562 search for usr/include, et al, within sysroot+headers_suffix. 13563 13564 -- Macro: EXTRA_SPECS 13565 Define this macro to provide additional specifications to put in 13566 the `specs' file that can be used in various specifications like 13567 `CC1_SPEC'. 13568 13569 The definition should be an initializer for an array of structures, 13570 containing a string constant, that defines the specification name, 13571 and a string constant that provides the specification. 13572 13573 Do not define this macro if it does not need to do anything. 13574 13575 `EXTRA_SPECS' is useful when an architecture contains several 13576 related targets, which have various `..._SPECS' which are similar 13577 to each other, and the maintainer would like one central place to 13578 keep these definitions. 13579 13580 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to 13581 define either `_CALL_SYSV' when the System V calling sequence is 13582 used or `_CALL_AIX' when the older AIX-based calling sequence is 13583 used. 13584 13585 The `config/rs6000/rs6000.h' target file defines: 13586 13587 #define EXTRA_SPECS \ 13588 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 13589 13590 #define CPP_SYS_DEFAULT "" 13591 13592 The `config/rs6000/sysv.h' target file defines: 13593 #undef CPP_SPEC 13594 #define CPP_SPEC \ 13595 "%{posix: -D_POSIX_SOURCE } \ 13596 %{mcall-sysv: -D_CALL_SYSV } \ 13597 %{!mcall-sysv: %(cpp_sysv_default) } \ 13598 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 13599 13600 #undef CPP_SYSV_DEFAULT 13601 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 13602 13603 while the `config/rs6000/eabiaix.h' target file defines 13604 `CPP_SYSV_DEFAULT' as: 13605 13606 #undef CPP_SYSV_DEFAULT 13607 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 13608 13609 -- Macro: LINK_LIBGCC_SPECIAL 13610 Define this macro if the driver program should find the library 13611 `libgcc.a' itself and should not pass `-L' options to the linker. 13612 If you do not define this macro, the driver program will pass the 13613 argument `-lgcc' to tell the linker to do the search and will pass 13614 `-L' options to it. 13615 13616 -- Macro: LINK_LIBGCC_SPECIAL_1 13617 Define this macro if the driver program should find the library 13618 `libgcc.a'. If you do not define this macro, the driver program 13619 will pass the argument `-lgcc' to tell the linker to do the search. 13620 This macro is similar to `LINK_LIBGCC_SPECIAL', except that it does 13621 not affect `-L' options. 13622 13623 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 13624 The sequence in which libgcc and libc are specified to the linker. 13625 By default this is `%G %L %G'. 13626 13627 -- Macro: LINK_COMMAND_SPEC 13628 A C string constant giving the complete command line need to 13629 execute the linker. When you do this, you will need to update 13630 your port each time a change is made to the link command line 13631 within `gcc.c'. Therefore, define this macro only if you need to 13632 completely redefine the command line for invoking the linker and 13633 there is no other way to accomplish the effect you need. 13634 Overriding this macro may be avoidable by overriding 13635 `LINK_GCC_C_SEQUENCE_SPEC' instead. 13636 13637 -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES 13638 A nonzero value causes `collect2' to remove duplicate 13639 `-LDIRECTORY' search directories from linking commands. Do not 13640 give it a nonzero value if removing duplicate search directories 13641 changes the linker's semantics. 13642 13643 -- Macro: MULTILIB_DEFAULTS 13644 Define this macro as a C expression for the initializer of an 13645 array of string to tell the driver program which options are 13646 defaults for this target and thus do not need to be handled 13647 specially when using `MULTILIB_OPTIONS'. 13648 13649 Do not define this macro if `MULTILIB_OPTIONS' is not defined in 13650 the target makefile fragment or if none of the options listed in 13651 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 13652 13653 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 13654 Define this macro to tell `gcc' that it should only translate a 13655 `-B' prefix into a `-L' linker option if the prefix indicates an 13656 absolute file name. 13657 13658 -- Macro: MD_EXEC_PREFIX 13659 If defined, this macro is an additional prefix to try after 13660 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the 13661 `-b' option is used, or the compiler is built as a cross compiler. 13662 If you define `MD_EXEC_PREFIX', then be sure to add it to the 13663 list of directories used to find the assembler in `configure.in'. 13664 13665 -- Macro: STANDARD_STARTFILE_PREFIX 13666 Define this macro as a C string constant if you wish to override 13667 the standard choice of `libdir' as the default prefix to try when 13668 searching for startup files such as `crt0.o'. 13669 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 13670 built as a cross compiler. 13671 13672 -- Macro: MD_STARTFILE_PREFIX 13673 If defined, this macro supplies an additional prefix to try after 13674 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the 13675 `-b' option is used, or when the compiler is built as a cross 13676 compiler. 13677 13678 -- Macro: MD_STARTFILE_PREFIX_1 13679 If defined, this macro supplies yet another prefix to try after the 13680 standard prefixes. It is not searched when the `-b' option is 13681 used, or when the compiler is built as a cross compiler. 13682 13683 -- Macro: INIT_ENVIRONMENT 13684 Define this macro as a C string constant if you wish to set 13685 environment variables for programs called by the driver, such as 13686 the assembler and loader. The driver passes the value of this 13687 macro to `putenv' to initialize the necessary environment 13688 variables. 13689 13690 -- Macro: LOCAL_INCLUDE_DIR 13691 Define this macro as a C string constant if you wish to override 13692 the standard choice of `/usr/local/include' as the default prefix 13693 to try when searching for local header files. `LOCAL_INCLUDE_DIR' 13694 comes before `SYSTEM_INCLUDE_DIR' in the search order. 13695 13696 Cross compilers do not search either `/usr/local/include' or its 13697 replacement. 13698 13699 -- Macro: MODIFY_TARGET_NAME 13700 Define this macro if you wish to define command-line switches that 13701 modify the default target name. 13702 13703 For each switch, you can include a string to be appended to the 13704 first part of the configuration name or a string to be deleted 13705 from the configuration name, if present. The definition should be 13706 an initializer for an array of structures. Each array element 13707 should have three elements: the switch name (a string constant, 13708 including the initial dash), one of the enumeration codes `ADD' or 13709 `DELETE' to indicate whether the string should be inserted or 13710 deleted, and the string to be inserted or deleted (a string 13711 constant). 13712 13713 For example, on a machine where `64' at the end of the 13714 configuration name denotes a 64-bit target and you want the `-32' 13715 and `-64' switches to select between 32- and 64-bit targets, you 13716 would code 13717 13718 #define MODIFY_TARGET_NAME \ 13719 { { "-32", DELETE, "64"}, \ 13720 {"-64", ADD, "64"}} 13721 13722 -- Macro: SYSTEM_INCLUDE_DIR 13723 Define this macro as a C string constant if you wish to specify a 13724 system-specific directory to search for header files before the 13725 standard directory. `SYSTEM_INCLUDE_DIR' comes before 13726 `STANDARD_INCLUDE_DIR' in the search order. 13727 13728 Cross compilers do not use this macro and do not search the 13729 directory specified. 13730 13731 -- Macro: STANDARD_INCLUDE_DIR 13732 Define this macro as a C string constant if you wish to override 13733 the standard choice of `/usr/include' as the default prefix to try 13734 when searching for header files. 13735 13736 Cross compilers ignore this macro and do not search either 13737 `/usr/include' or its replacement. 13738 13739 -- Macro: STANDARD_INCLUDE_COMPONENT 13740 The "component" corresponding to `STANDARD_INCLUDE_DIR'. See 13741 `INCLUDE_DEFAULTS', below, for the description of components. If 13742 you do not define this macro, no component is used. 13743 13744 -- Macro: INCLUDE_DEFAULTS 13745 Define this macro if you wish to override the entire default 13746 search path for include files. For a native compiler, the default 13747 search path usually consists of `GCC_INCLUDE_DIR', 13748 `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR', 13749 `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, 13750 `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined 13751 automatically by `Makefile', and specify private search areas for 13752 GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++ 13753 programs. 13754 13755 The definition should be an initializer for an array of structures. 13756 Each array element should have four elements: the directory name (a 13757 string constant), the component name (also a string constant), a 13758 flag for C++-only directories, and a flag showing that the 13759 includes in the directory don't need to be wrapped in `extern `C'' 13760 when compiling C++. Mark the end of the array with a null element. 13761 13762 The component name denotes what GNU package the include file is 13763 part of, if any, in all uppercase letters. For example, it might 13764 be `GCC' or `BINUTILS'. If the package is part of a 13765 vendor-supplied operating system, code the component name as `0'. 13766 13767 For example, here is the definition used for VAX/VMS: 13768 13769 #define INCLUDE_DEFAULTS \ 13770 { \ 13771 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 13772 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 13773 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 13774 { ".", 0, 0, 0}, \ 13775 { 0, 0, 0, 0} \ 13776 } 13777 13778 Here is the order of prefixes tried for exec files: 13779 13780 1. Any prefixes specified by the user with `-B'. 13781 13782 2. The environment variable `GCC_EXEC_PREFIX', if any. 13783 13784 3. The directories specified by the environment variable 13785 `COMPILER_PATH'. 13786 13787 4. The macro `STANDARD_EXEC_PREFIX'. 13788 13789 5. `/usr/lib/gcc/'. 13790 13791 6. The macro `MD_EXEC_PREFIX', if any. 13792 13793 Here is the order of prefixes tried for startfiles: 13794 13795 1. Any prefixes specified by the user with `-B'. 13796 13797 2. The environment variable `GCC_EXEC_PREFIX', if any. 13798 13799 3. The directories specified by the environment variable 13800 `LIBRARY_PATH' (or port-specific name; native only, cross 13801 compilers do not use this). 13802 13803 4. The macro `STANDARD_EXEC_PREFIX'. 13804 13805 5. `/usr/lib/gcc/'. 13806 13807 6. The macro `MD_EXEC_PREFIX', if any. 13808 13809 7. The macro `MD_STARTFILE_PREFIX', if any. 13810 13811 8. The macro `STANDARD_STARTFILE_PREFIX'. 13812 13813 9. `/lib/'. 13814 13815 10. `/usr/lib/'. 13816 13817 13818File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 13819 1382011.3 Run-time Target Specification 13821================================== 13822 13823Here are run-time target specifications. 13824 13825 -- Macro: TARGET_CPU_CPP_BUILTINS () 13826 This function-like macro expands to a block of code that defines 13827 built-in preprocessor macros and assertions for the target cpu, 13828 using the functions `builtin_define', `builtin_define_std' and 13829 `builtin_assert'. When the front end calls this macro it provides 13830 a trailing semicolon, and since it has finished command line 13831 option processing your code can use those results freely. 13832 13833 `builtin_assert' takes a string in the form you pass to the 13834 command-line option `-A', such as `cpu=mips', and creates the 13835 assertion. `builtin_define' takes a string in the form accepted 13836 by option `-D' and unconditionally defines the macro. 13837 13838 `builtin_define_std' takes a string representing the name of an 13839 object-like macro. If it doesn't lie in the user's namespace, 13840 `builtin_define_std' defines it unconditionally. Otherwise, it 13841 defines a version with two leading underscores, and another version 13842 with two leading and trailing underscores, and defines the original 13843 only if an ISO standard was not requested on the command line. For 13844 example, passing `unix' defines `__unix', `__unix__' and possibly 13845 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly 13846 `_mips', and passing `_ABI64' defines only `_ABI64'. 13847 13848 You can also test for the C dialect being compiled. The variable 13849 `c_language' is set to one of `clk_c', `clk_cplusplus' or 13850 `clk_objective_c'. Note that if we are preprocessing assembler, 13851 this variable will be `clk_c' but the function-like macro 13852 `preprocessing_asm_p()' will return true, so you might want to 13853 check for that first. If you need to check for strict ANSI, the 13854 variable `flag_iso' can be used. The function-like macro 13855 `preprocessing_trad_p()' can be used to check for traditional 13856 preprocessing. 13857 13858 -- Macro: TARGET_OS_CPP_BUILTINS () 13859 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 13860 and is used for the target operating system instead. 13861 13862 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 13863 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 13864 and is used for the target object format. `elfos.h' uses this 13865 macro to define `__ELF__', so you probably do not need to define 13866 it yourself. 13867 13868 -- Variable: extern int target_flags 13869 This declaration should be present. 13870 13871 -- Macro: TARGET_FEATURENAME 13872 This series of macros is to allow compiler command arguments to 13873 enable or disable the use of optional features of the target 13874 machine. For example, one machine description serves both the 13875 68000 and the 68020; a command argument tells the compiler whether 13876 it should use 68020-only instructions or not. This command 13877 argument works by means of a macro `TARGET_68020' that tests a bit 13878 in `target_flags'. 13879 13880 Define a macro `TARGET_FEATURENAME' for each such option. Its 13881 definition should test a bit in `target_flags'. It is recommended 13882 that a helper macro `MASK_FEATURENAME' is defined for each 13883 bit-value to test, and used in `TARGET_FEATURENAME' and 13884 `TARGET_SWITCHES'. For example: 13885 13886 #define TARGET_MASK_68020 1 13887 #define TARGET_68020 (target_flags & MASK_68020) 13888 13889 One place where these macros are used is in the 13890 condition-expressions of instruction patterns. Note how 13891 `TARGET_68020' appears frequently in the 68000 machine description 13892 file, `m68k.md'. Another place they are used is in the 13893 definitions of the other macros in the `MACHINE.h' file. 13894 13895 -- Macro: TARGET_SWITCHES 13896 This macro defines names of command options to set and clear bits 13897 in `target_flags'. Its definition is an initializer with a 13898 subgrouping for each command option. 13899 13900 Each subgrouping contains a string constant, that defines the 13901 option name, a number, which contains the bits to set in 13902 `target_flags', and a second string which is the description 13903 displayed by `--help'. If the number is negative then the bits 13904 specified by the number are cleared instead of being set. If the 13905 description string is present but empty, then no help information 13906 will be displayed for that option, but it will not count as an 13907 undocumented option. The actual option name is made by appending 13908 `-m' to the specified name. Non-empty description strings should 13909 be marked with `N_(...)' for `xgettext'. Please do not mark empty 13910 strings because the empty string is reserved by GNU gettext. 13911 `gettext("")' returns the header entry of the message catalog with 13912 meta information, not the empty string. 13913 13914 In addition to the description for `--help', more detailed 13915 documentation for each option should be added to `invoke.texi'. 13916 13917 One of the subgroupings should have a null string. The number in 13918 this grouping is the default value for `target_flags'. Any target 13919 options act starting with that value. 13920 13921 Here is an example which defines `-m68000' and `-m68020' with 13922 opposite meanings, and picks the latter as the default: 13923 13924 #define TARGET_SWITCHES \ 13925 { { "68020", MASK_68020, "" }, \ 13926 { "68000", -MASK_68020, \ 13927 N_("Compile for the 68000") }, \ 13928 { "", MASK_68020, "" }, \ 13929 } 13930 13931 -- Macro: TARGET_OPTIONS 13932 This macro is similar to `TARGET_SWITCHES' but defines names of 13933 command options that have values. Its definition is an 13934 initializer with a subgrouping for each command option. 13935 13936 Each subgrouping contains a string constant, that defines the 13937 option name, the address of a variable, a description string, and 13938 a value. Non-empty description strings should be marked with 13939 `N_(...)' for `xgettext'. Please do not mark empty strings 13940 because the empty string is reserved by GNU gettext. `gettext("")' 13941 returns the header entry of the message catalog with meta 13942 information, not the empty string. 13943 13944 If the value listed in the table is `NULL', then the variable, type 13945 `char *', is set to the variable part of the given option if the 13946 fixed part matches. In other words, if the first part of the 13947 option matches what's in the table, the variable will be set to 13948 point to the rest of the option. This allows the user to specify 13949 a value for that option. The actual option name is made by 13950 appending `-m' to the specified name. Again, each option should 13951 also be documented in `invoke.texi'. 13952 13953 If the value listed in the table is non-`NULL', then the option 13954 must match the option in the table exactly (with `-m'), and the 13955 variable is set to point to the value listed in the table. 13956 13957 Here is an example which defines `-mshort-data-NUMBER'. If the 13958 given option is `-mshort-data-512', the variable `m88k_short_data' 13959 will be set to the string `"512"'. 13960 13961 extern char *m88k_short_data; 13962 #define TARGET_OPTIONS \ 13963 { { "short-data-", &m88k_short_data, \ 13964 N_("Specify the size of the short data section"), 0 } } 13965 13966 Here is a variant of the above that allows the user to also specify 13967 just `-mshort-data' where a default of `"64"' is used. 13968 13969 extern char *m88k_short_data; 13970 #define TARGET_OPTIONS \ 13971 { { "short-data-", &m88k_short_data, \ 13972 N_("Specify the size of the short data section"), 0 } \ 13973 { "short-data", &m88k_short_data, "", "64" }, 13974 } 13975 13976 Here is an example which defines `-mno-alu', `-malu1', and 13977 `-malu2' as a three-state switch, along with suitable macros for 13978 checking the state of the option (documentation is elided for 13979 brevity). 13980 13981 [chip.c] 13982 char *chip_alu = ""; /* Specify default here. */ 13983 13984 [chip.h] 13985 extern char *chip_alu; 13986 #define TARGET_OPTIONS \ 13987 { { "no-alu", &chip_alu, "", "" }, \ 13988 { "alu1", &chip_alu, "", "1" }, \ 13989 { "alu2", &chip_alu, "", "2" }, } 13990 #define TARGET_ALU (chip_alu[0] != '\0') 13991 #define TARGET_ALU1 (chip_alu[0] == '1') 13992 #define TARGET_ALU2 (chip_alu[0] == '2') 13993 13994 -- Macro: TARGET_VERSION 13995 This macro is a C statement to print on `stderr' a string 13996 describing the particular machine description choice. Every 13997 machine description should define `TARGET_VERSION'. For example: 13998 13999 #ifdef MOTOROLA 14000 #define TARGET_VERSION \ 14001 fprintf (stderr, " (68k, Motorola syntax)"); 14002 #else 14003 #define TARGET_VERSION \ 14004 fprintf (stderr, " (68k, MIT syntax)"); 14005 #endif 14006 14007 -- Macro: OVERRIDE_OPTIONS 14008 Sometimes certain combinations of command options do not make 14009 sense on a particular target machine. You can define a macro 14010 `OVERRIDE_OPTIONS' to take account of this. This macro, if 14011 defined, is executed once just after all the command options have 14012 been parsed. 14013 14014 Don't use this macro to turn on various extra optimizations for 14015 `-O'. That is what `OPTIMIZATION_OPTIONS' is for. 14016 14017 -- Macro: OPTIMIZATION_OPTIONS (LEVEL, SIZE) 14018 Some machines may desire to change what optimizations are 14019 performed for various optimization levels. This macro, if 14020 defined, is executed once just after the optimization level is 14021 determined and before the remainder of the command options have 14022 been parsed. Values set in this macro are used as the default 14023 values for the other command line options. 14024 14025 LEVEL is the optimization level specified; 2 if `-O2' is 14026 specified, 1 if `-O' is specified, and 0 if neither is specified. 14027 14028 SIZE is nonzero if `-Os' is specified and zero otherwise. 14029 14030 You should not use this macro to change options that are not 14031 machine-specific. These should uniformly selected by the same 14032 optimization level on all supported machines. Use this macro to 14033 enable machine-specific optimizations. 14034 14035 *Do not examine `write_symbols' in this macro!* The debugging 14036 options are not supposed to alter the generated code. 14037 14038 -- Macro: CAN_DEBUG_WITHOUT_FP 14039 Define this macro if debugging can be performed even without a 14040 frame pointer. If this macro is defined, GCC will turn on the 14041 `-fomit-frame-pointer' option whenever `-O' is specified. 14042 14043 14044File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 14045 1404611.4 Defining data structures for per-function information. 14047=========================================================== 14048 14049If the target needs to store information on a per-function basis, GCC 14050provides a macro and a couple of variables to allow this. Note, just 14051using statics to store the information is a bad idea, since GCC supports 14052nested functions, so you can be halfway through encoding one function 14053when another one comes along. 14054 14055 GCC defines a data structure called `struct function' which contains 14056all of the data specific to an individual function. This structure 14057contains a field called `machine' whose type is `struct 14058machine_function *', which can be used by targets to point to their own 14059specific data. 14060 14061 If a target needs per-function specific data it should define the 14062type `struct machine_function' and also the macro `INIT_EXPANDERS'. 14063This macro should be used to initialize the function pointer 14064`init_machine_status'. This pointer is explained below. 14065 14066 One typical use of per-function, target specific data is to create an 14067RTX to hold the register containing the function's return address. This 14068RTX can then be used to implement the `__builtin_return_address' 14069function, for level 0. 14070 14071 Note--earlier implementations of GCC used a single data area to hold 14072all of the per-function information. Thus when processing of a nested 14073function began the old per-function data had to be pushed onto a stack, 14074and when the processing was finished, it had to be popped off the 14075stack. GCC used to provide function pointers called 14076`save_machine_status' and `restore_machine_status' to handle the saving 14077and restoring of the target specific information. Since the single 14078data area approach is no longer used, these pointers are no longer 14079supported. 14080 14081 -- Macro: INIT_EXPANDERS 14082 Macro called to initialize any target specific information. This 14083 macro is called once per function, before generation of any RTL 14084 has begun. The intention of this macro is to allow the 14085 initialization of the function pointer `init_machine_status'. 14086 14087 -- Variable: void (*)(struct function *) init_machine_status 14088 If this function pointer is non-`NULL' it will be called once per 14089 function, before function compilation starts, in order to allow the 14090 target to perform any target specific initialization of the 14091 `struct function' structure. It is intended that this would be 14092 used to initialize the `machine' of that structure. 14093 14094 `struct machine_function' structures are expected to be freed by 14095 GC. Generally, any memory that they reference must be allocated 14096 by using `ggc_alloc', including the structure itself. 14097 14098 14099File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 14100 1410111.5 Storage Layout 14102=================== 14103 14104Note that the definitions of the macros in this table which are sizes or 14105alignments measured in bits do not need to be constant. They can be C 14106expressions that refer to static variables, such as the `target_flags'. 14107*Note Run-time Target::. 14108 14109 -- Macro: BITS_BIG_ENDIAN 14110 Define this macro to have the value 1 if the most significant bit 14111 in a byte has the lowest number; otherwise define it to have the 14112 value zero. This means that bit-field instructions count from the 14113 most significant bit. If the machine has no bit-field 14114 instructions, then this must still be defined, but it doesn't 14115 matter which value it is defined to. This macro need not be a 14116 constant. 14117 14118 This macro does not affect the way structure fields are packed into 14119 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. 14120 14121 -- Macro: BYTES_BIG_ENDIAN 14122 Define this macro to have the value 1 if the most significant byte 14123 in a word has the lowest number. This macro need not be a 14124 constant. 14125 14126 -- Macro: WORDS_BIG_ENDIAN 14127 Define this macro to have the value 1 if, in a multiword object, 14128 the most significant word has the lowest number. This applies to 14129 both memory locations and registers; GCC fundamentally assumes 14130 that the order of words in memory is the same as the order in 14131 registers. This macro need not be a constant. 14132 14133 -- Macro: LIBGCC2_WORDS_BIG_ENDIAN 14134 Define this macro if `WORDS_BIG_ENDIAN' is not constant. This 14135 must be a constant value with the same meaning as 14136 `WORDS_BIG_ENDIAN', which will be used only when compiling 14137 `libgcc2.c'. Typically the value will be set based on 14138 preprocessor defines. 14139 14140 -- Macro: FLOAT_WORDS_BIG_ENDIAN 14141 Define this macro to have the value 1 if `DFmode', `XFmode' or 14142 `TFmode' floating point numbers are stored in memory with the word 14143 containing the sign bit at the lowest address; otherwise define it 14144 to have the value 0. This macro need not be a constant. 14145 14146 You need not define this macro if the ordering is the same as for 14147 multi-word integers. 14148 14149 -- Macro: BITS_PER_UNIT 14150 Define this macro to be the number of bits in an addressable 14151 storage unit (byte). If you do not define this macro the default 14152 is 8. 14153 14154 -- Macro: BITS_PER_WORD 14155 Number of bits in a word. If you do not define this macro, the 14156 default is `BITS_PER_UNIT * UNITS_PER_WORD'. 14157 14158 -- Macro: MAX_BITS_PER_WORD 14159 Maximum number of bits in a word. If this is undefined, the 14160 default is `BITS_PER_WORD'. Otherwise, it is the constant value 14161 that is the largest value that `BITS_PER_WORD' can have at 14162 run-time. 14163 14164 -- Macro: UNITS_PER_WORD 14165 Number of storage units in a word; normally 4. 14166 14167 -- Macro: MIN_UNITS_PER_WORD 14168 Minimum number of units in a word. If this is undefined, the 14169 default is `UNITS_PER_WORD'. Otherwise, it is the constant value 14170 that is the smallest value that `UNITS_PER_WORD' can have at 14171 run-time. 14172 14173 -- Macro: POINTER_SIZE 14174 Width of a pointer, in bits. You must specify a value no wider 14175 than the width of `Pmode'. If it is not equal to the width of 14176 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do 14177 not specify a value the default is `BITS_PER_WORD'. 14178 14179 -- Macro: POINTERS_EXTEND_UNSIGNED 14180 A C expression whose value is greater than zero if pointers that 14181 need to be extended from being `POINTER_SIZE' bits wide to `Pmode' 14182 are to be zero-extended and zero if they are to be sign-extended. 14183 If the value is less then zero then there must be an "ptr_extend" 14184 instruction that extends a pointer from `POINTER_SIZE' to `Pmode'. 14185 14186 You need not define this macro if the `POINTER_SIZE' is equal to 14187 the width of `Pmode'. 14188 14189 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 14190 A macro to update M and UNSIGNEDP when an object whose type is 14191 TYPE and which has the specified mode and signedness is to be 14192 stored in a register. This macro is only called when TYPE is a 14193 scalar type. 14194 14195 On most RISC machines, which only have operations that operate on 14196 a full register, define this macro to set M to `word_mode' if M is 14197 an integer mode narrower than `BITS_PER_WORD'. In most cases, 14198 only integer modes should be widened because wider-precision 14199 floating-point operations are usually more expensive than their 14200 narrower counterparts. 14201 14202 For most machines, the macro definition does not change UNSIGNEDP. 14203 However, some machines, have instructions that preferentially 14204 handle either signed or unsigned quantities of certain modes. For 14205 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 14206 instructions sign-extend the result to 64 bits. On such machines, 14207 set UNSIGNEDP according to which kind of extension is more 14208 efficient. 14209 14210 Do not define this macro if it would never modify M. 14211 14212 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_ARGS (tree FNTYPE) 14213 This target hook should return `true' if the promotion described by 14214 `PROMOTE_MODE' should also be done for outgoing function arguments. 14215 14216 -- Target Hook: bool TARGET_PROMOTE_FUNCTION_RETURN (tree FNTYPE) 14217 This target hook should return `true' if the promotion described by 14218 `PROMOTE_MODE' should also be done for the return value of 14219 functions. 14220 14221 If this target hook returns `true', `FUNCTION_VALUE' must perform 14222 the same promotions done by `PROMOTE_MODE'. 14223 14224 -- Macro: PROMOTE_FOR_CALL_ONLY 14225 Define this macro if the promotion described by `PROMOTE_MODE' 14226 should _only_ be performed for outgoing function arguments or 14227 function return values, as specified by 14228 `TARGET_PROMOTE_FUNCTION_ARGS' and 14229 `TARGET_PROMOTE_FUNCTION_RETURN', respectively. 14230 14231 -- Macro: PARM_BOUNDARY 14232 Normal alignment required for function parameters on the stack, in 14233 bits. All stack parameters receive at least this much alignment 14234 regardless of data type. On most machines, this is the same as the 14235 size of an integer. 14236 14237 -- Macro: STACK_BOUNDARY 14238 Define this macro to the minimum alignment enforced by hardware 14239 for the stack pointer on this machine. The definition is a C 14240 expression for the desired alignment (measured in bits). This 14241 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not 14242 defined. On most machines, this should be the same as 14243 `PARM_BOUNDARY'. 14244 14245 -- Macro: PREFERRED_STACK_BOUNDARY 14246 Define this macro if you wish to preserve a certain alignment for 14247 the stack pointer, greater than what the hardware enforces. The 14248 definition is a C expression for the desired alignment (measured 14249 in bits). This macro must evaluate to a value equal to or larger 14250 than `STACK_BOUNDARY'. 14251 14252 -- Macro: FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN 14253 A C expression that evaluates true if `PREFERRED_STACK_BOUNDARY' is 14254 not guaranteed by the runtime and we should emit code to align the 14255 stack at the beginning of `main'. 14256 14257 If `PUSH_ROUNDING' is not defined, the stack will always be aligned 14258 to the specified boundary. If `PUSH_ROUNDING' is defined and 14259 specifies a less strict alignment than `PREFERRED_STACK_BOUNDARY', 14260 the stack may be momentarily unaligned while pushing arguments. 14261 14262 -- Macro: FUNCTION_BOUNDARY 14263 Alignment required for a function entry point, in bits. 14264 14265 -- Macro: BIGGEST_ALIGNMENT 14266 Biggest alignment that any data type can require on this machine, 14267 in bits. 14268 14269 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 14270 If defined, the smallest alignment, in bits, that can be given to 14271 an object that can be referenced in one operation, without 14272 disturbing any nearby object. Normally, this is `BITS_PER_UNIT', 14273 but may be larger on machines that don't have byte or half-word 14274 store operations. 14275 14276 -- Macro: BIGGEST_FIELD_ALIGNMENT 14277 Biggest alignment that any structure or union field can require on 14278 this machine, in bits. If defined, this overrides 14279 `BIGGEST_ALIGNMENT' for structure and union fields only, unless 14280 the field alignment has been set by the `__attribute__ ((aligned 14281 (N)))' construct. 14282 14283 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 14284 An expression for the alignment of a structure field FIELD if the 14285 alignment computed in the usual way (including applying of 14286 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the 14287 alignment) is COMPUTED. It overrides alignment only if the field 14288 alignment has not been set by the `__attribute__ ((aligned (N)))' 14289 construct. 14290 14291 -- Macro: MAX_OFILE_ALIGNMENT 14292 Biggest alignment supported by the object file format of this 14293 machine. Use this macro to limit the alignment which can be 14294 specified using the `__attribute__ ((aligned (N)))' construct. If 14295 not defined, the default value is `BIGGEST_ALIGNMENT'. 14296 14297 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 14298 If defined, a C expression to compute the alignment for a variable 14299 in the static store. TYPE is the data type, and BASIC-ALIGN is 14300 the alignment that the object would ordinarily have. The value of 14301 this macro is used instead of that alignment to align the object. 14302 14303 If this macro is not defined, then BASIC-ALIGN is used. 14304 14305 One use of this macro is to increase alignment of medium-size data 14306 to make it all fit in fewer cache lines. Another is to cause 14307 character arrays to be word-aligned so that `strcpy' calls that 14308 copy constants to character arrays can be done inline. 14309 14310 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 14311 If defined, a C expression to compute the alignment given to a 14312 constant that is being placed in memory. CONSTANT is the constant 14313 and BASIC-ALIGN is the alignment that the object would ordinarily 14314 have. The value of this macro is used instead of that alignment to 14315 align the object. 14316 14317 If this macro is not defined, then BASIC-ALIGN is used. 14318 14319 The typical use of this macro is to increase alignment for string 14320 constants to be word aligned so that `strcpy' calls that copy 14321 constants can be done inline. 14322 14323 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 14324 If defined, a C expression to compute the alignment for a variable 14325 in the local store. TYPE is the data type, and BASIC-ALIGN is the 14326 alignment that the object would ordinarily have. The value of this 14327 macro is used instead of that alignment to align the object. 14328 14329 If this macro is not defined, then BASIC-ALIGN is used. 14330 14331 One use of this macro is to increase alignment of medium-size data 14332 to make it all fit in fewer cache lines. 14333 14334 -- Macro: EMPTY_FIELD_BOUNDARY 14335 Alignment in bits to be given to a structure bit-field that 14336 follows an empty field such as `int : 0;'. 14337 14338 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 14339 14340 -- Macro: STRUCTURE_SIZE_BOUNDARY 14341 Number of bits which any structure or union's size must be a 14342 multiple of. Each structure or union's size is rounded up to a 14343 multiple of this. 14344 14345 If you do not define this macro, the default is the same as 14346 `BITS_PER_UNIT'. 14347 14348 -- Macro: STRICT_ALIGNMENT 14349 Define this macro to be the value 1 if instructions will fail to 14350 work if given data not on the nominal alignment. If instructions 14351 will merely go slower in that case, define this macro as 0. 14352 14353 -- Macro: PCC_BITFIELD_TYPE_MATTERS 14354 Define this if you wish to imitate the way many other C compilers 14355 handle alignment of bit-fields and the structures that contain 14356 them. 14357 14358 The behavior is that the type written for a named bit-field (`int', 14359 `short', or other integer type) imposes an alignment for the entire 14360 structure, as if the structure really did contain an ordinary 14361 field of that type. In addition, the bit-field is placed within 14362 the structure so that it would fit within such a field, not 14363 crossing a boundary for it. 14364 14365 Thus, on most machines, a named bit-field whose type is written as 14366 `int' would not cross a four-byte boundary, and would force 14367 four-byte alignment for the whole structure. (The alignment used 14368 may not be four bytes; it is controlled by the other alignment 14369 parameters.) 14370 14371 An unnamed bit-field will not affect the alignment of the 14372 containing structure. 14373 14374 If the macro is defined, its definition should be a C expression; 14375 a nonzero value for the expression enables this behavior. 14376 14377 Note that if this macro is not defined, or its value is zero, some 14378 bit-fields may cross more than one alignment boundary. The 14379 compiler can support such references if there are `insv', `extv', 14380 and `extzv' insns that can directly reference memory. 14381 14382 The other known way of making bit-fields work is to define 14383 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then 14384 every structure can be accessed with fullwords. 14385 14386 Unless the machine has bit-field instructions or you define 14387 `STRUCTURE_SIZE_BOUNDARY' that way, you must define 14388 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 14389 14390 If your aim is to make GCC use the same conventions for laying out 14391 bit-fields as are used by another compiler, here is how to 14392 investigate what the other compiler does. Compile and run this 14393 program: 14394 14395 struct foo1 14396 { 14397 char x; 14398 char :0; 14399 char y; 14400 }; 14401 14402 struct foo2 14403 { 14404 char x; 14405 int :0; 14406 char y; 14407 }; 14408 14409 main () 14410 { 14411 printf ("Size of foo1 is %d\n", 14412 sizeof (struct foo1)); 14413 printf ("Size of foo2 is %d\n", 14414 sizeof (struct foo2)); 14415 exit (0); 14416 } 14417 14418 If this prints 2 and 5, then the compiler's behavior is what you 14419 would get from `PCC_BITFIELD_TYPE_MATTERS'. 14420 14421 -- Macro: BITFIELD_NBYTES_LIMITED 14422 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 14423 to aligning a bit-field within the structure. 14424 14425 -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE) 14426 Return 1 if a structure or array containing FIELD should be 14427 accessed using `BLKMODE'. 14428 14429 If FIELD is the only field in the structure, MODE is its mode, 14430 otherwise MODE is VOIDmode. MODE is provided in the case where 14431 structures of one field would require the structure's mode to 14432 retain the field's mode. 14433 14434 Normally, this is not needed. See the file `c4x.h' for an example 14435 of how to use this macro to prevent a structure having a floating 14436 point field from being accessed in an integer mode. 14437 14438 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 14439 Define this macro as an expression for the alignment of a type 14440 (given by TYPE as a tree node) if the alignment computed in the 14441 usual way is COMPUTED and the alignment explicitly specified was 14442 SPECIFIED. 14443 14444 The default is to use SPECIFIED if it is larger; otherwise, use 14445 the smaller of COMPUTED and `BIGGEST_ALIGNMENT' 14446 14447 -- Macro: MAX_FIXED_MODE_SIZE 14448 An integer expression for the size in bits of the largest integer 14449 machine mode that should actually be used. All integer machine 14450 modes of this size or smaller can be used for structures and 14451 unions with the appropriate sizes. If this macro is undefined, 14452 `GET_MODE_BITSIZE (DImode)' is assumed. 14453 14454 -- Macro: VECTOR_MODE_SUPPORTED_P (MODE) 14455 Define this macro to be nonzero if the port is prepared to handle 14456 insns involving vector mode MODE. At the very least, it must have 14457 move patterns for this mode. 14458 14459 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 14460 If defined, an expression of type `enum machine_mode' that 14461 specifies the mode of the save area operand of a 14462 `save_stack_LEVEL' named pattern (*note Standard Names::). 14463 SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or 14464 `SAVE_NONLOCAL' and selects which of the three named patterns is 14465 having its mode specified. 14466 14467 You need not define this macro if it always returns `Pmode'. You 14468 would most commonly define this macro if the `save_stack_LEVEL' 14469 patterns need to support both a 32- and a 64-bit mode. 14470 14471 -- Macro: STACK_SIZE_MODE 14472 If defined, an expression of type `enum machine_mode' that 14473 specifies the mode of the size increment operand of an 14474 `allocate_stack' named pattern (*note Standard Names::). 14475 14476 You need not define this macro if it always returns `word_mode'. 14477 You would most commonly define this macro if the `allocate_stack' 14478 pattern needs to support both a 32- and a 64-bit mode. 14479 14480 -- Macro: TARGET_FLOAT_FORMAT 14481 A code distinguishing the floating point format of the target 14482 machine. There are four defined values: 14483 14484 `IEEE_FLOAT_FORMAT' 14485 This code indicates IEEE floating point. It is the default; 14486 there is no need to define `TARGET_FLOAT_FORMAT' when the 14487 format is IEEE. 14488 14489 `VAX_FLOAT_FORMAT' 14490 This code indicates the "F float" (for `float') and "D float" 14491 or "G float" formats (for `double') used on the VAX and 14492 PDP-11. 14493 14494 `IBM_FLOAT_FORMAT' 14495 This code indicates the format used on the IBM System/370. 14496 14497 `C4X_FLOAT_FORMAT' 14498 This code indicates the format used on the TMS320C3x/C4x. 14499 14500 If your target uses a floating point format other than these, you 14501 must define a new NAME_FLOAT_FORMAT code for it, and add support 14502 for it to `real.c'. 14503 14504 The ordering of the component words of floating point values 14505 stored in memory is controlled by `FLOAT_WORDS_BIG_ENDIAN'. 14506 14507 -- Macro: MODE_HAS_NANS (MODE) 14508 When defined, this macro should be true if MODE has a NaN 14509 representation. The compiler assumes that NaNs are not equal to 14510 anything (including themselves) and that addition, subtraction, 14511 multiplication and division all return NaNs when one operand is 14512 NaN. 14513 14514 By default, this macro is true if MODE is a floating-point mode 14515 and the target floating-point format is IEEE. 14516 14517 -- Macro: MODE_HAS_INFINITIES (MODE) 14518 This macro should be true if MODE can represent infinity. At 14519 present, the compiler uses this macro to decide whether `x - x' is 14520 always defined. By default, the macro is true when MODE is a 14521 floating-point mode and the target format is IEEE. 14522 14523 -- Macro: MODE_HAS_SIGNED_ZEROS (MODE) 14524 True if MODE distinguishes between positive and negative zero. 14525 The rules are expected to follow the IEEE standard: 14526 14527 * `x + x' has the same sign as `x'. 14528 14529 * If the sum of two values with opposite sign is zero, the 14530 result is positive for all rounding modes expect towards 14531 -infinity, for which it is negative. 14532 14533 * The sign of a product or quotient is negative when exactly one 14534 of the operands is negative. 14535 14536 The default definition is true if MODE is a floating-point mode 14537 and the target format is IEEE. 14538 14539 -- Macro: MODE_HAS_SIGN_DEPENDENT_ROUNDING (MODE) 14540 If defined, this macro should be true for MODE if it has at least 14541 one rounding mode in which `x' and `-x' can be rounded to numbers 14542 of different magnitude. Two such modes are towards -infinity and 14543 towards +infinity. 14544 14545 The default definition of this macro is true if MODE is a 14546 floating-point mode and the target format is IEEE. 14547 14548 -- Macro: ROUND_TOWARDS_ZERO 14549 If defined, this macro should be true if the prevailing rounding 14550 mode is towards zero. A true value has the following effects: 14551 14552 * `MODE_HAS_SIGN_DEPENDENT_ROUNDING' will be false for all 14553 modes. 14554 14555 * `libgcc.a''s floating-point emulator will round towards zero 14556 rather than towards nearest. 14557 14558 * The compiler's floating-point emulator will round towards 14559 zero after doing arithmetic, and when converting from the 14560 internal float format to the target format. 14561 14562 The macro does not affect the parsing of string literals. When the 14563 primary rounding mode is towards zero, library functions like 14564 `strtod' might still round towards nearest, and the compiler's 14565 parser should behave like the target's `strtod' where possible. 14566 14567 Not defining this macro is equivalent to returning zero. 14568 14569 -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE) 14570 This macro should return true if floats with SIZE bits do not have 14571 a NaN or infinity representation, but use the largest exponent for 14572 normal numbers instead. 14573 14574 Defining this macro to true for SIZE causes `MODE_HAS_NANS' and 14575 `MODE_HAS_INFINITIES' to be false for SIZE-bit modes. It also 14576 affects the way `libgcc.a' and `real.c' emulate floating-point 14577 arithmetic. 14578 14579 The default definition of this macro returns false for all sizes. 14580 14581 -- Target Hook: bool TARGET_VECTOR_OPAQUE_P (tree TYPE) 14582 This target hook should return `true' a vector is opaque. That 14583 is, if no cast is needed when copying a vector value of type TYPE 14584 into another vector lvalue of the same size. Vector opaque types 14585 cannot be initialized. The default is that there are no such 14586 types. 14587 14588 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree RECORD_TYPE) 14589 This target hook returns `true' if bit-fields in the given 14590 RECORD_TYPE are to be laid out following the rules of Microsoft 14591 Visual C/C++, namely: (i) a bit-field won't share the same storage 14592 unit with the previous bit-field if their underlying types have 14593 different sizes, and the bit-field will be aligned to the highest 14594 alignment of the underlying types of itself and of the previous 14595 bit-field; (ii) a zero-sized bit-field will affect the alignment of 14596 the whole enclosing structure, even if it is unnamed; except that 14597 (iii) a zero-sized bit-field will be disregarded unless it follows 14598 another bit-field of nonzero size. If this hook returns `true', 14599 other macros that control bit-field layout are ignored. 14600 14601 When a bit-field is inserted into a packed record, the whole size 14602 of the underlying type is used by one or more same-size adjacent 14603 bit-fields (that is, if its long:3, 32 bits is used in the record, 14604 and any additional adjacent long bit-fields are packed into the 14605 same chunk of 32 bits. However, if the size changes, a new field 14606 of that size is allocated). In an unpacked record, this is the 14607 same as using alignment, but not equivalent when packing. 14608 14609 If both MS bit-fields and `__attribute__((packed))' are used, the 14610 latter will take precedence. If `__attribute__((packed))' is used 14611 on a single field when MS bit-fields are in use, it will take 14612 precedence for that field, but the alignment of the rest of the 14613 structure may affect its placement. 14614 14615 -- Target Hook: const char * TARGET_MANGLE_FUNDAMENTAL_TYPE (tree TYPE) 14616 If your target defines any fundamental types, define this hook to 14617 return the appropriate encoding for these types as part of a C++ 14618 mangled name. The TYPE argument is the tree structure 14619 representing the type to be mangled. The hook may be applied to 14620 trees which are not target-specific fundamental types; it should 14621 return `NULL' for all such types, as well as arguments it does not 14622 recognize. If the return value is not `NULL', it must point to a 14623 statically-allocated string constant. 14624 14625 Target-specific fundamental types might be new fundamental types or 14626 qualified versions of ordinary fundamental types. Encode new 14627 fundamental types as `u N NAME', where NAME is the name used for 14628 the type in source code, and N is the length of NAME in decimal. 14629 Encode qualified versions of ordinary types as `U N NAME CODE', 14630 where NAME is the name used for the type qualifier in source code, 14631 N is the length of NAME as above, and CODE is the code used to 14632 represent the unqualified version of this type. (See 14633 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In 14634 both cases the spaces are for clarity; do not include any spaces 14635 in your string. 14636 14637 The default version of this hook always returns `NULL', which is 14638 appropriate for a target that does not define any new fundamental 14639 types. 14640 14641 14642File: gccint.info, Node: Type Layout, Next: Escape Sequences, Prev: Storage Layout, Up: Target Macros 14643 1464411.6 Layout of Source Language Data Types 14645========================================= 14646 14647These macros define the sizes and other characteristics of the standard 14648basic data types used in programs being compiled. Unlike the macros in 14649the previous section, these apply to specific features of C and related 14650languages, rather than to fundamental aspects of storage layout. 14651 14652 -- Macro: INT_TYPE_SIZE 14653 A C expression for the size in bits of the type `int' on the 14654 target machine. If you don't define this, the default is one word. 14655 14656 -- Macro: SHORT_TYPE_SIZE 14657 A C expression for the size in bits of the type `short' on the 14658 target machine. If you don't define this, the default is half a 14659 word. (If this would be less than one storage unit, it is rounded 14660 up to one unit.) 14661 14662 -- Macro: LONG_TYPE_SIZE 14663 A C expression for the size in bits of the type `long' on the 14664 target machine. If you don't define this, the default is one word. 14665 14666 -- Macro: ADA_LONG_TYPE_SIZE 14667 On some machines, the size used for the Ada equivalent of the type 14668 `long' by a native Ada compiler differs from that used by C. In 14669 that situation, define this macro to be a C expression to be used 14670 for the size of that type. If you don't define this, the default 14671 is the value of `LONG_TYPE_SIZE'. 14672 14673 -- Macro: MAX_LONG_TYPE_SIZE 14674 Maximum number for the size in bits of the type `long' on the 14675 target machine. If this is undefined, the default is 14676 `LONG_TYPE_SIZE'. Otherwise, it is the constant value that is the 14677 largest value that `LONG_TYPE_SIZE' can have at run-time. This is 14678 used in `cpp'. 14679 14680 -- Macro: LONG_LONG_TYPE_SIZE 14681 A C expression for the size in bits of the type `long long' on the 14682 target machine. If you don't define this, the default is two 14683 words. If you want to support GNU Ada on your machine, the value 14684 of this macro must be at least 64. 14685 14686 -- Macro: CHAR_TYPE_SIZE 14687 A C expression for the size in bits of the type `char' on the 14688 target machine. If you don't define this, the default is 14689 `BITS_PER_UNIT'. 14690 14691 -- Macro: BOOL_TYPE_SIZE 14692 A C expression for the size in bits of the C++ type `bool' and C99 14693 type `_Bool' on the target machine. If you don't define this, and 14694 you probably shouldn't, the default is `CHAR_TYPE_SIZE'. 14695 14696 -- Macro: FLOAT_TYPE_SIZE 14697 A C expression for the size in bits of the type `float' on the 14698 target machine. If you don't define this, the default is one word. 14699 14700 -- Macro: DOUBLE_TYPE_SIZE 14701 A C expression for the size in bits of the type `double' on the 14702 target machine. If you don't define this, the default is two 14703 words. 14704 14705 -- Macro: LONG_DOUBLE_TYPE_SIZE 14706 A C expression for the size in bits of the type `long double' on 14707 the target machine. If you don't define this, the default is two 14708 words. 14709 14710 -- Macro: MAX_LONG_DOUBLE_TYPE_SIZE 14711 Maximum number for the size in bits of the type `long double' on 14712 the target machine. If this is undefined, the default is 14713 `LONG_DOUBLE_TYPE_SIZE'. Otherwise, it is the constant value that 14714 is the largest value that `LONG_DOUBLE_TYPE_SIZE' can have at 14715 run-time. This is used in `cpp'. 14716 14717 -- Macro: TARGET_FLT_EVAL_METHOD 14718 A C expression for the value for `FLT_EVAL_METHOD' in `float.h', 14719 assuming, if applicable, that the floating-point control word is 14720 in its default state. If you do not define this macro the value of 14721 `FLT_EVAL_METHOD' will be zero. 14722 14723 -- Macro: WIDEST_HARDWARE_FP_SIZE 14724 A C expression for the size in bits of the widest floating-point 14725 format supported by the hardware. If you define this macro, you 14726 must specify a value less than or equal to the value of 14727 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 14728 value of `LONG_DOUBLE_TYPE_SIZE' is the default. 14729 14730 -- Macro: DEFAULT_SIGNED_CHAR 14731 An expression whose value is 1 or 0, according to whether the type 14732 `char' should be signed or unsigned by default. The user can 14733 always override this default with the options `-fsigned-char' and 14734 `-funsigned-char'. 14735 14736 -- Macro: DEFAULT_SHORT_ENUMS 14737 A C expression to determine whether to give an `enum' type only as 14738 many bytes as it takes to represent the range of possible values 14739 of that type. A nonzero value means to do that; a zero value 14740 means all `enum' types should be allocated like `int'. 14741 14742 If you don't define the macro, the default is 0. 14743 14744 -- Macro: SIZE_TYPE 14745 A C expression for a string describing the name of the data type 14746 to use for size values. The typedef name `size_t' is defined 14747 using the contents of the string. 14748 14749 The string can contain more than one keyword. If so, separate 14750 them with spaces, and write first any length keyword, then 14751 `unsigned' if appropriate, and finally `int'. The string must 14752 exactly match one of the data type names defined in the function 14753 `init_decl_processing' in the file `c-decl.c'. You may not omit 14754 `int' or change the order--that would cause the compiler to crash 14755 on startup. 14756 14757 If you don't define this macro, the default is `"long unsigned 14758 int"'. 14759 14760 -- Macro: PTRDIFF_TYPE 14761 A C expression for a string describing the name of the data type 14762 to use for the result of subtracting two pointers. The typedef 14763 name `ptrdiff_t' is defined using the contents of the string. See 14764 `SIZE_TYPE' above for more information. 14765 14766 If you don't define this macro, the default is `"long int"'. 14767 14768 -- Macro: WCHAR_TYPE 14769 A C expression for a string describing the name of the data type 14770 to use for wide characters. The typedef name `wchar_t' is defined 14771 using the contents of the string. See `SIZE_TYPE' above for more 14772 information. 14773 14774 If you don't define this macro, the default is `"int"'. 14775 14776 -- Macro: WCHAR_TYPE_SIZE 14777 A C expression for the size in bits of the data type for wide 14778 characters. This is used in `cpp', which cannot make use of 14779 `WCHAR_TYPE'. 14780 14781 -- Macro: MAX_WCHAR_TYPE_SIZE 14782 Maximum number for the size in bits of the data type for wide 14783 characters. If this is undefined, the default is 14784 `WCHAR_TYPE_SIZE'. Otherwise, it is the constant value that is the 14785 largest value that `WCHAR_TYPE_SIZE' can have at run-time. This is 14786 used in `cpp'. 14787 14788 -- Macro: GCOV_TYPE_SIZE 14789 A C expression for the size in bits of the type used for gcov 14790 counters on the target machine. If you don't define this, the 14791 default is one `LONG_TYPE_SIZE' in case it is greater or equal to 14792 64-bit and `LONG_LONG_TYPE_SIZE' otherwise. You may want to 14793 re-define the type to ensure atomicity for counters in 14794 multithreaded programs. 14795 14796 -- Macro: WINT_TYPE 14797 A C expression for a string describing the name of the data type to 14798 use for wide characters passed to `printf' and returned from 14799 `getwc'. The typedef name `wint_t' is defined using the contents 14800 of the string. See `SIZE_TYPE' above for more information. 14801 14802 If you don't define this macro, the default is `"unsigned int"'. 14803 14804 -- Macro: INTMAX_TYPE 14805 A C expression for a string describing the name of the data type 14806 that can represent any value of any standard or extended signed 14807 integer type. The typedef name `intmax_t' is defined using the 14808 contents of the string. See `SIZE_TYPE' above for more 14809 information. 14810 14811 If you don't define this macro, the default is the first of 14812 `"int"', `"long int"', or `"long long int"' that has as much 14813 precision as `long long int'. 14814 14815 -- Macro: UINTMAX_TYPE 14816 A C expression for a string describing the name of the data type 14817 that can represent any value of any standard or extended unsigned 14818 integer type. The typedef name `uintmax_t' is defined using the 14819 contents of the string. See `SIZE_TYPE' above for more 14820 information. 14821 14822 If you don't define this macro, the default is the first of 14823 `"unsigned int"', `"long unsigned int"', or `"long long unsigned 14824 int"' that has as much precision as `long long unsigned int'. 14825 14826 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 14827 The C++ compiler represents a pointer-to-member-function with a 14828 struct that looks like: 14829 14830 struct { 14831 union { 14832 void (*fn)(); 14833 ptrdiff_t vtable_index; 14834 }; 14835 ptrdiff_t delta; 14836 }; 14837 14838 The C++ compiler must use one bit to indicate whether the function 14839 that will be called through a pointer-to-member-function is 14840 virtual. Normally, we assume that the low-order bit of a function 14841 pointer must always be zero. Then, by ensuring that the 14842 vtable_index is odd, we can distinguish which variant of the union 14843 is in use. But, on some platforms function pointers can be odd, 14844 and so this doesn't work. In that case, we use the low-order bit 14845 of the `delta' field, and shift the remainder of the `delta' field 14846 to the left. 14847 14848 GCC will automatically make the right selection about where to 14849 store this bit using the `FUNCTION_BOUNDARY' setting for your 14850 platform. However, some platforms such as ARM/Thumb have 14851 `FUNCTION_BOUNDARY' set such that functions always start at even 14852 addresses, but the lowest bit of pointers to functions indicate 14853 whether the function at that address is in ARM or Thumb mode. If 14854 this is the case of your architecture, you should define this 14855 macro to `ptrmemfunc_vbit_in_delta'. 14856 14857 In general, you should not have to define this macro. On 14858 architectures in which function addresses are always even, 14859 according to `FUNCTION_BOUNDARY', GCC will automatically define 14860 this macro to `ptrmemfunc_vbit_in_pfn'. 14861 14862 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 14863 Normally, the C++ compiler uses function pointers in vtables. This 14864 macro allows the target to change to use "function descriptors" 14865 instead. Function descriptors are found on targets for whom a 14866 function pointer is actually a small data structure. Normally the 14867 data structure consists of the actual code address plus a data 14868 pointer to which the function's data is relative. 14869 14870 If vtables are used, the value of this macro should be the number 14871 of words that the function descriptor occupies. 14872 14873 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 14874 By default, the vtable entries are void pointers, the so the 14875 alignment is the same as pointer alignment. The value of this 14876 macro specifies the alignment of the vtable entry in bits. It 14877 should be defined only when special alignment is necessary. */ 14878 14879 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 14880 There are a few non-descriptor entries in the vtable at offsets 14881 below zero. If these entries must be padded (say, to preserve the 14882 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to 14883 the number of words in each data entry. 14884 14885 14886File: gccint.info, Node: Escape Sequences, Next: Registers, Prev: Type Layout, Up: Target Macros 14887 1488811.7 Target Character Escape Sequences 14889====================================== 14890 14891By default, GCC assumes that the C character escape sequences take on 14892their ASCII values for the target. If this is not correct, you must 14893explicitly define all of the macros below. All of them must evaluate 14894to constants; they are used in `case' statements. 14895 14896Macro Escape ASCII character 14897`TARGET_BELL' `\a' `07', `BEL' 14898`TARGET_CR' `\r' `0D', `CR' 14899`TARGET_ESC' `\e', `1B', `ESC' 14900 `\E' 14901`TARGET_FF' `\f' `0C', `FF' 14902`TARGET_NEWLINE' `\n' `0A', `LF' 14903`TARGET_TAB' `\t' `09', `HT' 14904`TARGET_VT' `\v' `0B', `VT' 14905 14906Note that the `\e' and `\E' escapes are GNU extensions, not part of the 14907C standard. 14908 14909 14910File: gccint.info, Node: Registers, Next: Register Classes, Prev: Escape Sequences, Up: Target Macros 14911 1491211.8 Register Usage 14913=================== 14914 14915This section explains how to describe what registers the target machine 14916has, and how (in general) they can be used. 14917 14918 The description of which registers a specific instruction can use is 14919done with register classes; see *Note Register Classes::. For 14920information on using registers to access a stack frame, see *Note Frame 14921Registers::. For passing values in registers, see *Note Register 14922Arguments::. For returning values in registers, see *Note Scalar 14923Return::. 14924 14925* Menu: 14926 14927* Register Basics:: Number and kinds of registers. 14928* Allocation Order:: Order in which registers are allocated. 14929* Values in Registers:: What kinds of values each reg can hold. 14930* Leaf Functions:: Renumbering registers for leaf functions. 14931* Stack Registers:: Handling a register stack such as 80387. 14932 14933 14934File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 14935 1493611.8.1 Basic Characteristics of Registers 14937----------------------------------------- 14938 14939Registers have various characteristics. 14940 14941 -- Macro: FIRST_PSEUDO_REGISTER 14942 Number of hardware registers known to the compiler. They receive 14943 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first 14944 pseudo register's number really is assigned the number 14945 `FIRST_PSEUDO_REGISTER'. 14946 14947 -- Macro: FIXED_REGISTERS 14948 An initializer that says which registers are used for fixed 14949 purposes all throughout the compiled code and are therefore not 14950 available for general allocation. These would include the stack 14951 pointer, the frame pointer (except on machines where that can be 14952 used as a general register when no frame pointer is needed), the 14953 program counter on machines where that is considered one of the 14954 addressable registers, and any other numbered register with a 14955 standard use. 14956 14957 This information is expressed as a sequence of numbers, separated 14958 by commas and surrounded by braces. The Nth number is 1 if 14959 register N is fixed, 0 otherwise. 14960 14961 The table initialized from this macro, and the table initialized by 14962 the following one, may be overridden at run time either 14963 automatically, by the actions of the macro 14964 `CONDITIONAL_REGISTER_USAGE', or by the user with the command 14965 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. 14966 14967 -- Macro: CALL_USED_REGISTERS 14968 Like `FIXED_REGISTERS' but has 1 for each register that is 14969 clobbered (in general) by function calls as well as for fixed 14970 registers. This macro therefore identifies the registers that are 14971 not available for general allocation of values that must live 14972 across function calls. 14973 14974 If a register has 0 in `CALL_USED_REGISTERS', the compiler 14975 automatically saves it on function entry and restores it on 14976 function exit, if the register is used within the function. 14977 14978 -- Macro: CALL_REALLY_USED_REGISTERS 14979 Like `CALL_USED_REGISTERS' except this macro doesn't require that 14980 the entire set of `FIXED_REGISTERS' be included. 14981 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS'). 14982 This macro is optional. If not specified, it defaults to the value 14983 of `CALL_USED_REGISTERS'. 14984 14985 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 14986 A C expression that is nonzero if it is not permissible to store a 14987 value of mode MODE in hard register number REGNO across a call 14988 without some part of it being clobbered. For most machines this 14989 macro need not be defined. It is only required for machines that 14990 do not preserve the entire contents of a register across a call. 14991 14992 -- Macro: CONDITIONAL_REGISTER_USAGE 14993 Zero or more C statements that may conditionally modify five 14994 variables `fixed_regs', `call_used_regs', `global_regs', 14995 `reg_names', and `reg_class_contents', to take into account any 14996 dependence of these register sets on target flags. The first three 14997 of these are of type `char []' (interpreted as Boolean vectors). 14998 `global_regs' is a `const char *[]', and `reg_class_contents' is a 14999 `HARD_REG_SET'. Before the macro is called, `fixed_regs', 15000 `call_used_regs', `reg_class_contents', and `reg_names' have been 15001 initialized from `FIXED_REGISTERS', `CALL_USED_REGISTERS', 15002 `REG_CLASS_CONTENTS', and `REGISTER_NAMES', respectively. 15003 `global_regs' has been cleared, and any `-ffixed-REG', 15004 `-fcall-used-REG' and `-fcall-saved-REG' command options have been 15005 applied. 15006 15007 You need not define this macro if it has no work to do. 15008 15009 If the usage of an entire class of registers depends on the target 15010 flags, you may indicate this to GCC by using this macro to modify 15011 `fixed_regs' and `call_used_regs' to 1 for each of the registers 15012 in the classes which should not be used by GCC. Also define the 15013 macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to 15014 return `NO_REGS' if it is called with a letter for a class that 15015 shouldn't be used. 15016 15017 (However, if this class is not included in `GENERAL_REGS' and all 15018 of the insn patterns whose constraints permit this class are 15019 controlled by target switches, then GCC will automatically avoid 15020 using these registers when the target switches are opposed to 15021 them.) 15022 15023 -- Macro: NON_SAVING_SETJMP 15024 If this macro is defined and has a nonzero value, it means that 15025 `setjmp' and related functions fail to save the registers, or that 15026 `longjmp' fails to restore them. To compensate, the compiler 15027 avoids putting variables in registers in functions that use 15028 `setjmp'. 15029 15030 -- Macro: INCOMING_REGNO (OUT) 15031 Define this macro if the target machine has register windows. 15032 This C expression returns the register number as seen by the 15033 called function corresponding to the register number OUT as seen 15034 by the calling function. Return OUT if register number OUT is not 15035 an outbound register. 15036 15037 -- Macro: OUTGOING_REGNO (IN) 15038 Define this macro if the target machine has register windows. 15039 This C expression returns the register number as seen by the 15040 calling function corresponding to the register number IN as seen 15041 by the called function. Return IN if register number IN is not an 15042 inbound register. 15043 15044 -- Macro: LOCAL_REGNO (REGNO) 15045 Define this macro if the target machine has register windows. 15046 This C expression returns true if the register is call-saved but 15047 is in the register window. Unlike most call-saved registers, such 15048 registers need not be explicitly restored on function exit or 15049 during non-local gotos. 15050 15051 -- Macro: PC_REGNUM 15052 If the program counter has a register number, define this as that 15053 register number. Otherwise, do not define it. 15054 15055 15056File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 15057 1505811.8.2 Order of Allocation of Registers 15059--------------------------------------- 15060 15061Registers are allocated in order. 15062 15063 -- Macro: REG_ALLOC_ORDER 15064 If defined, an initializer for a vector of integers, containing the 15065 numbers of hard registers in the order in which GCC should prefer 15066 to use them (from most preferred to least). 15067 15068 If this macro is not defined, registers are used lowest numbered 15069 first (all else being equal). 15070 15071 One use of this macro is on machines where the highest numbered 15072 registers must always be saved and the save-multiple-registers 15073 instruction supports only sequences of consecutive registers. On 15074 such machines, define `REG_ALLOC_ORDER' to be an initializer that 15075 lists the highest numbered allocable register first. 15076 15077 -- Macro: ORDER_REGS_FOR_LOCAL_ALLOC 15078 A C statement (sans semicolon) to choose the order in which to 15079 allocate hard registers for pseudo-registers local to a basic 15080 block. 15081 15082 Store the desired register order in the array `reg_alloc_order'. 15083 Element 0 should be the register to allocate first; element 1, the 15084 next register; and so on. 15085 15086 The macro body should not assume anything about the contents of 15087 `reg_alloc_order' before execution of the macro. 15088 15089 On most machines, it is not necessary to define this macro. 15090 15091 15092File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 15093 1509411.8.3 How Values Fit in Registers 15095---------------------------------- 15096 15097This section discusses the macros that describe which kinds of values 15098(specifically, which machine modes) each register can hold, and how many 15099consecutive registers are needed for a given mode. 15100 15101 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 15102 A C expression for the number of consecutive hard registers, 15103 starting at register number REGNO, required to hold a value of mode 15104 MODE. 15105 15106 On a machine where all registers are exactly one word, a suitable 15107 definition of this macro is 15108 15109 #define HARD_REGNO_NREGS(REGNO, MODE) \ 15110 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 15111 / UNITS_PER_WORD) 15112 15113 -- Macro: REGMODE_NATURAL_SIZE (MODE) 15114 Define this macro if the natural size of registers that hold values 15115 of mode MODE is not the word size. It is a C expression that 15116 should give the natural size in bytes for the specified mode. It 15117 is used by the register allocator to try to optimize its results. 15118 This happens for example on SPARC 64-bit where the natural size of 15119 floating-point registers is still 32-bit. 15120 15121 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 15122 A C expression that is nonzero if it is permissible to store a 15123 value of mode MODE in hard register number REGNO (or in several 15124 registers starting with that one). For a machine where all 15125 registers are equivalent, a suitable definition is 15126 15127 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 15128 15129 You need not include code to check for the numbers of fixed 15130 registers, because the allocation mechanism considers them to be 15131 always occupied. 15132 15133 On some machines, double-precision values must be kept in even/odd 15134 register pairs. You can implement that by defining this macro to 15135 reject odd register numbers for such modes. 15136 15137 The minimum requirement for a mode to be OK in a register is that 15138 the `movMODE' instruction pattern support moves between the 15139 register and other hard register in the same class and that moving 15140 a value into the register and back out not alter it. 15141 15142 Since the same instruction used to move `word_mode' will work for 15143 all narrower integer modes, it is not necessary on any machine for 15144 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided 15145 you define patterns `movhi', etc., to take advantage of this. This 15146 is useful because of the interaction between `HARD_REGNO_MODE_OK' 15147 and `MODES_TIEABLE_P'; it is very desirable for all integer modes 15148 to be tieable. 15149 15150 Many machines have special registers for floating point arithmetic. 15151 Often people assume that floating point machine modes are allowed 15152 only in floating point registers. This is not true. Any 15153 registers that can hold integers can safely _hold_ a floating 15154 point machine mode, whether or not floating arithmetic can be done 15155 on it in those registers. Integer move instructions can be used 15156 to move the values. 15157 15158 On some machines, though, the converse is true: fixed-point machine 15159 modes may not go in floating registers. This is true if the 15160 floating registers normalize any value stored in them, because 15161 storing a non-floating value there would garble it. In this case, 15162 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 15163 floating registers. But if the floating registers do not 15164 automatically normalize, if you can store any bit pattern in one 15165 and retrieve it unchanged without a trap, then any machine mode 15166 may go in a floating register, so you can define this macro to say 15167 so. 15168 15169 The primary significance of special floating registers is rather 15170 that they are the registers acceptable in floating point arithmetic 15171 instructions. However, this is of no concern to 15172 `HARD_REGNO_MODE_OK'. You handle it by writing the proper 15173 constraints for those instructions. 15174 15175 On some machines, the floating registers are especially slow to 15176 access, so that it is better to store a value in a stack frame 15177 than in such a register if floating point arithmetic is not being 15178 done. As long as the floating registers are not in class 15179 `GENERAL_REGS', they will not be used unless some pattern's 15180 constraint asks for one. 15181 15182 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 15183 A C expression that is nonzero if a value of mode MODE1 is 15184 accessible in mode MODE2 without copying. 15185 15186 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, 15187 MODE2)' are always the same for any R, then `MODES_TIEABLE_P 15188 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 15189 should define this macro to return zero unless some other 15190 mechanism ensures the accessibility of the value in a narrower 15191 mode. 15192 15193 You should define this macro to return nonzero in as many cases as 15194 possible since doing so will allow GCC to perform better register 15195 allocation. 15196 15197 -- Macro: AVOID_CCMODE_COPIES 15198 Define this macro if the compiler should avoid copies to/from 15199 `CCmode' registers. You should only define this macro if support 15200 for copying to/from `CCmode' is incomplete. 15201 15202 15203File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 15204 1520511.8.4 Handling Leaf Functions 15206------------------------------ 15207 15208On some machines, a leaf function (i.e., one which makes no calls) can 15209run more efficiently if it does not make its own register window. 15210Often this means it is required to receive its arguments in the 15211registers where they are passed by the caller, instead of the registers 15212where they would normally arrive. 15213 15214 The special treatment for leaf functions generally applies only when 15215other conditions are met; for example, often they may use only those 15216registers for its own variables and temporaries. We use the term "leaf 15217function" to mean a function that is suitable for this special 15218handling, so that functions with no calls are not necessarily "leaf 15219functions". 15220 15221 GCC assigns register numbers before it knows whether the function is 15222suitable for leaf function treatment. So it needs to renumber the 15223registers in order to output a leaf function. The following macros 15224accomplish this. 15225 15226 -- Macro: LEAF_REGISTERS 15227 Name of a char vector, indexed by hard register number, which 15228 contains 1 for a register that is allowable in a candidate for leaf 15229 function treatment. 15230 15231 If leaf function treatment involves renumbering the registers, 15232 then the registers marked here should be the ones before 15233 renumbering--those that GCC would ordinarily allocate. The 15234 registers which will actually be used in the assembler code, after 15235 renumbering, should not be marked with 1 in this vector. 15236 15237 Define this macro only if the target machine offers a way to 15238 optimize the treatment of leaf functions. 15239 15240 -- Macro: LEAF_REG_REMAP (REGNO) 15241 A C expression whose value is the register number to which REGNO 15242 should be renumbered, when a function is treated as a leaf 15243 function. 15244 15245 If REGNO is a register number which should not appear in a leaf 15246 function before renumbering, then the expression should yield -1, 15247 which will cause the compiler to abort. 15248 15249 Define this macro only if the target machine offers a way to 15250 optimize the treatment of leaf functions, and registers need to be 15251 renumbered to do this. 15252 15253 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 15254must usually treat leaf functions specially. They can test the C 15255variable `current_function_is_leaf' which is nonzero for leaf 15256functions. `current_function_is_leaf' is set prior to local register 15257allocation and is valid for the remaining compiler passes. They can 15258also test the C variable `current_function_uses_only_leaf_regs' which 15259is nonzero for leaf functions which only use leaf registers. 15260`current_function_uses_only_leaf_regs' is valid after reload and is 15261only useful if `LEAF_REGISTERS' is defined. 15262 15263 15264File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 15265 1526611.8.5 Registers That Form a Stack 15267---------------------------------- 15268 15269There are special features to handle computers where some of the 15270"registers" form a stack. Stack registers are normally written by 15271pushing onto the stack, and are numbered relative to the top of the 15272stack. 15273 15274 Currently, GCC can only handle one group of stack-like registers, and 15275they must be consecutively numbered. Furthermore, the existing support 15276for stack-like registers is specific to the 80387 floating point 15277coprocessor. If you have a new architecture that uses stack-like 15278registers, you will need to do substantial work on `reg-stack.c' and 15279write your machine description to cooperate with it, as well as 15280defining these macros. 15281 15282 -- Macro: STACK_REGS 15283 Define this if the machine has any stack-like registers. 15284 15285 -- Macro: FIRST_STACK_REG 15286 The number of the first stack-like register. This one is the top 15287 of the stack. 15288 15289 -- Macro: LAST_STACK_REG 15290 The number of the last stack-like register. This one is the 15291 bottom of the stack. 15292 15293 15294File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 15295 1529611.9 Register Classes 15297===================== 15298 15299On many machines, the numbered registers are not all equivalent. For 15300example, certain registers may not be allowed for indexed addressing; 15301certain registers may not be allowed in some instructions. These 15302machine restrictions are described to the compiler using "register 15303classes". 15304 15305 You define a number of register classes, giving each one a name and 15306saying which of the registers belong to it. Then you can specify 15307register classes that are allowed as operands to particular instruction 15308patterns. 15309 15310 In general, each register will belong to several classes. In fact, 15311one class must be named `ALL_REGS' and contain all the registers. 15312Another class must be named `NO_REGS' and contain no registers. Often 15313the union of two classes will be another class; however, this is not 15314required. 15315 15316 One of the classes must be named `GENERAL_REGS'. There is nothing 15317terribly special about the name, but the operand constraint letters `r' 15318and `g' specify this class. If `GENERAL_REGS' is the same as 15319`ALL_REGS', just define it as a macro which expands to `ALL_REGS'. 15320 15321 Order the classes so that if class X is contained in class Y then X 15322has a lower class number than Y. 15323 15324 The way classes other than `GENERAL_REGS' are specified in operand 15325constraints is through machine-dependent operand constraint letters. 15326You can define such letters to correspond to various classes, then use 15327them in operand constraints. 15328 15329 You should define a class for the union of two classes whenever some 15330instruction allows both classes. For example, if an instruction allows 15331either a floating point (coprocessor) register or a general register 15332for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' 15333which includes both of them. Otherwise you will get suboptimal code. 15334 15335 You must also specify certain redundant information about the 15336register classes: for each class, which classes contain it and which 15337ones are contained in it; for each pair of classes, the largest class 15338contained in their union. 15339 15340 When a value occupying several consecutive registers is expected in a 15341certain class, all the registers used must belong to that class. 15342Therefore, register classes cannot be used to enforce a requirement for 15343a register pair to start with an even-numbered register. The way to 15344specify this requirement is with `HARD_REGNO_MODE_OK'. 15345 15346 Register classes used for input-operands of bitwise-and or shift 15347instructions have a special requirement: each such class must have, for 15348each fixed-point machine mode, a subclass whose registers can transfer 15349that mode to or from memory. For example, on some machines, the 15350operations for single-byte values (`QImode') are limited to certain 15351registers. When this is so, each register class that is used in a 15352bitwise-and or shift instruction must have a subclass consisting of 15353registers from which single-byte values can be loaded or stored. This 15354is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to 15355return. 15356 15357 -- Data type: enum reg_class 15358 An enumerated type that must be defined with all the register 15359 class names as enumerated values. `NO_REGS' must be first. 15360 `ALL_REGS' must be the last register class, followed by one more 15361 enumerated value, `LIM_REG_CLASSES', which is not a register class 15362 but rather tells how many classes there are. 15363 15364 Each register class has a number, which is the value of casting 15365 the class name to type `int'. The number serves as an index in 15366 many of the tables described below. 15367 15368 -- Macro: N_REG_CLASSES 15369 The number of distinct register classes, defined as follows: 15370 15371 #define N_REG_CLASSES (int) LIM_REG_CLASSES 15372 15373 -- Macro: REG_CLASS_NAMES 15374 An initializer containing the names of the register classes as C 15375 string constants. These names are used in writing some of the 15376 debugging dumps. 15377 15378 -- Macro: REG_CLASS_CONTENTS 15379 An initializer containing the contents of the register classes, as 15380 integers which are bit masks. The Nth integer specifies the 15381 contents of class N. The way the integer MASK is interpreted is 15382 that register R is in the class if `MASK & (1 << R)' is 1. 15383 15384 When the machine has more than 32 registers, an integer does not 15385 suffice. Then the integers are replaced by sub-initializers, 15386 braced groupings containing several integers. Each 15387 sub-initializer must be suitable as an initializer for the type 15388 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this 15389 situation, the first integer in each sub-initializer corresponds to 15390 registers 0 through 31, the second integer to registers 32 through 15391 63, and so on. 15392 15393 -- Macro: REGNO_REG_CLASS (REGNO) 15394 A C expression whose value is a register class containing hard 15395 register REGNO. In general there is more than one such class; 15396 choose a class which is "minimal", meaning that no smaller class 15397 also contains the register. 15398 15399 -- Macro: BASE_REG_CLASS 15400 A macro whose definition is the name of the class to which a valid 15401 base register must belong. A base register is one used in an 15402 address which is the register value plus a displacement. 15403 15404 -- Macro: MODE_BASE_REG_CLASS (MODE) 15405 This is a variation of the `BASE_REG_CLASS' macro which allows the 15406 selection of a base register in a mode dependent manner. If MODE 15407 is VOIDmode then it should return the same value as 15408 `BASE_REG_CLASS'. 15409 15410 -- Macro: INDEX_REG_CLASS 15411 A macro whose definition is the name of the class to which a valid 15412 index register must belong. An index register is one used in an 15413 address where its value is either multiplied by a scale factor or 15414 added to another register (as well as added to a displacement). 15415 15416 -- Macro: CONSTRAINT_LEN (CHAR, STR) 15417 For the constraint at the start of STR, which starts with the 15418 letter C, return the length. This allows you to have register 15419 class / constant / extra constraints that are longer than a single 15420 letter; you don't need to define this macro if you can do with 15421 single-letter constraints only. The definition of this macro 15422 should use DEFAULT_CONSTRAINT_LEN for all the characters that you 15423 don't want to handle specially. There are some sanity checks in 15424 genoutput.c that check the constraint lengths for the md file, so 15425 you can also use this macro to help you while you are 15426 transitioning from a byzantine single-letter-constraint scheme: 15427 when you return a negative length for a constraint you want to 15428 re-use, genoutput will complain about every instance where it is 15429 used in the md file. 15430 15431 -- Macro: REG_CLASS_FROM_LETTER (CHAR) 15432 A C expression which defines the machine-dependent operand 15433 constraint letters for register classes. If CHAR is such a 15434 letter, the value should be the register class corresponding to 15435 it. Otherwise, the value should be `NO_REGS'. The register 15436 letter `r', corresponding to class `GENERAL_REGS', will not be 15437 passed to this macro; you do not need to handle it. 15438 15439 -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR) 15440 Like `REG_CLASS_FROM_LETTER', but you also get the constraint 15441 string passed in STR, so that you can use suffixes to distinguish 15442 between different variants. 15443 15444 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 15445 A C expression which is nonzero if register number NUM is suitable 15446 for use as a base register in operand addresses. It may be either 15447 a suitable hard register or a pseudo register that has been 15448 allocated such a hard register. 15449 15450 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 15451 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that 15452 that expression may examine the mode of the memory reference in 15453 MODE. You should define this macro if the mode of the memory 15454 reference affects whether a register may be used as a base 15455 register. If you define this macro, the compiler will use it 15456 instead of `REGNO_OK_FOR_BASE_P'. 15457 15458 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 15459 A C expression which is nonzero if register number NUM is suitable 15460 for use as an index register in operand addresses. It may be 15461 either a suitable hard register or a pseudo register that has been 15462 allocated such a hard register. 15463 15464 The difference between an index register and a base register is 15465 that the index register may be scaled. If an address involves the 15466 sum of two registers, neither one of them scaled, then either one 15467 may be labeled the "base" and the other the "index"; but whichever 15468 labeling is used must fit the machine's constraints of which 15469 registers may serve in each capacity. The compiler will try both 15470 labelings, looking for one that is valid, and will reload one or 15471 both registers only if neither labeling works. 15472 15473 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 15474 A C expression that places additional restrictions on the register 15475 class to use when it is necessary to copy value X into a register 15476 in class CLASS. The value is a register class; perhaps CLASS, or 15477 perhaps another, smaller class. On many machines, the following 15478 definition is safe: 15479 15480 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 15481 15482 Sometimes returning a more restrictive class makes better code. 15483 For example, on the 68000, when X is an integer constant that is 15484 in range for a `moveq' instruction, the value of this macro is 15485 always `DATA_REGS' as long as CLASS includes the data registers. 15486 Requiring a data register guarantees that a `moveq' will be used. 15487 15488 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is 15489 if X is a legitimate constant which cannot be loaded into some 15490 register class. By returning `NO_REGS' you can force X into a 15491 memory location. For example, rs6000 can load immediate values 15492 into general-purpose registers, but does not have an instruction 15493 for loading an immediate value into a floating-point register, so 15494 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a 15495 floating-point constant. If the constant can't be loaded into any 15496 kind of register, code generation will be better if 15497 `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of 15498 using `PREFERRED_RELOAD_CLASS'. 15499 15500 -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS) 15501 Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of 15502 input reloads. If you don't define this macro, the default is to 15503 use CLASS, unchanged. 15504 15505 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 15506 A C expression that places additional restrictions on the register 15507 class to use when it is necessary to be able to hold a value of 15508 mode MODE in a reload register for which class CLASS would 15509 ordinarily be used. 15510 15511 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when 15512 there are certain modes that simply can't go in certain reload 15513 classes. 15514 15515 The value is a register class; perhaps CLASS, or perhaps another, 15516 smaller class. 15517 15518 Don't define this macro unless the target machine has limitations 15519 which require the macro to do something nontrivial. 15520 15521 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 15522 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 15523 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 15524 Many machines have some registers that cannot be copied directly 15525 to or from memory or even from other types of registers. An 15526 example is the `MQ' register, which on most machines, can only be 15527 copied to or from general registers, but not memory. Some 15528 machines allow copying all registers to and from memory, but 15529 require a scratch register for stores to some memory locations 15530 (e.g., those with symbolic address on the RT, and those with 15531 certain symbolic address on the SPARC when compiling PIC). In 15532 some cases, both an intermediate and a scratch register are 15533 required. 15534 15535 You should define these macros to indicate to the reload phase 15536 that it may need to allocate at least one register for a reload in 15537 addition to the register to contain the data. Specifically, if 15538 copying X to a register CLASS in MODE requires an intermediate 15539 register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to 15540 return the largest register class all of whose registers can be 15541 used as intermediate registers or scratch registers. 15542 15543 If copying a register CLASS in MODE to X requires an intermediate 15544 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be 15545 defined to return the largest register class required. If the 15546 requirements for input and output reloads are the same, the macro 15547 `SECONDARY_RELOAD_CLASS' should be used instead of defining both 15548 macros identically. 15549 15550 The values returned by these macros are often `GENERAL_REGS'. 15551 Return `NO_REGS' if no spare register is needed; i.e., if X can be 15552 directly copied to or from a register of CLASS in MODE without 15553 requiring a scratch register. Do not define this macro if it 15554 would always return `NO_REGS'. 15555 15556 If a scratch register is required (either with or without an 15557 intermediate register), you should define patterns for 15558 `reload_inM' or `reload_outM', as required (*note Standard 15559 Names::. These patterns, which will normally be implemented with 15560 a `define_expand', should be similar to the `movM' patterns, 15561 except that operand 2 is the scratch register. 15562 15563 Define constraints for the reload register and scratch register 15564 that contain a single register class. If the original reload 15565 register (whose class is CLASS) can meet the constraint given in 15566 the pattern, the value returned by these macros is used for the 15567 class of the scratch register. Otherwise, two additional reload 15568 registers are required. Their classes are obtained from the 15569 constraints in the insn pattern. 15570 15571 X might be a pseudo-register or a `subreg' of a pseudo-register, 15572 which could either be in a hard register or in memory. Use 15573 `true_regnum' to find out; it will return -1 if the pseudo is in 15574 memory and the hard register number if it is in a register. 15575 15576 These macros should not be used in the case where a particular 15577 class of registers can only be copied to memory and not to another 15578 class of registers. In that case, secondary reload registers are 15579 not needed and would not be helpful. Instead, a stack location 15580 must be used to perform the copy and the `movM' pattern should use 15581 memory as an intermediate storage. This case often occurs between 15582 floating-point and general registers. 15583 15584 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 15585 Certain machines have the property that some registers cannot be 15586 copied to some other registers without using memory. Define this 15587 macro on those machines to be a C expression that is nonzero if 15588 objects of mode M in registers of CLASS1 can only be copied to 15589 registers of class CLASS2 by storing a register of CLASS1 into 15590 memory and loading that memory location into a register of CLASS2. 15591 15592 Do not define this macro if its value would always be zero. 15593 15594 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 15595 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler 15596 allocates a stack slot for a memory location needed for register 15597 copies. If this macro is defined, the compiler instead uses the 15598 memory location defined by this macro. 15599 15600 Do not define this macro if you do not define 15601 `SECONDARY_MEMORY_NEEDED'. 15602 15603 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 15604 When the compiler needs a secondary memory location to copy 15605 between two registers of mode MODE, it normally allocates 15606 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and 15607 performs the store and load operations in a mode that many bits 15608 wide and whose class is the same as that of MODE. 15609 15610 This is right thing to do on most machines because it ensures that 15611 all bits of the register are copied and prevents accesses to the 15612 registers in a narrower mode, which some machines prohibit for 15613 floating-point registers. 15614 15615 However, this default behavior is not correct on some machines, 15616 such as the DEC Alpha, that store short integers in floating-point 15617 registers differently than in integer registers. On those 15618 machines, the default widening will not work correctly and you 15619 must define this macro to suppress that widening in some cases. 15620 See the file `alpha.h' for details. 15621 15622 Do not define this macro if you do not define 15623 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 15624 `BITS_PER_WORD' bits wide is correct for your machine. 15625 15626 -- Macro: SMALL_REGISTER_CLASSES 15627 On some machines, it is risky to let hard registers live across 15628 arbitrary insns. Typically, these machines have instructions that 15629 require values to be in specific registers (like an accumulator), 15630 and reload will fail if the required hard register is used for 15631 another purpose across such an insn. 15632 15633 Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero 15634 value on these machines. When this macro has a nonzero value, the 15635 compiler will try to minimize the lifetime of hard registers. 15636 15637 It is always safe to define this macro with a nonzero value, but 15638 if you unnecessarily define it, you will reduce the amount of 15639 optimizations that can be performed in some cases. If you do not 15640 define this macro with a nonzero value when it is required, the 15641 compiler will run out of spill registers and print a fatal error 15642 message. For most machines, you should not define this macro at 15643 all. 15644 15645 -- Macro: CLASS_LIKELY_SPILLED_P (CLASS) 15646 A C expression whose value is nonzero if pseudos that have been 15647 assigned to registers of class CLASS would likely be spilled 15648 because registers of CLASS are needed for spill registers. 15649 15650 The default value of this macro returns 1 if CLASS has exactly one 15651 register and zero otherwise. On most machines, this default 15652 should be used. Only define this macro to some other expression 15653 if pseudos allocated by `local-alloc.c' end up in memory because 15654 their hard registers were needed for spill registers. If this 15655 macro returns nonzero for those classes, those pseudos will only 15656 be allocated by `global.c', which knows how to reallocate the 15657 pseudo to another register. If there would not be another 15658 register available for reallocation, you should not change the 15659 definition of this macro since the only effect of such a 15660 definition would be to slow down register allocation. 15661 15662 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 15663 A C expression for the maximum number of consecutive registers of 15664 class CLASS needed to hold a value of mode MODE. 15665 15666 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 15667 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be 15668 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all 15669 REGNO values in the class CLASS. 15670 15671 This macro helps control the handling of multiple-word values in 15672 the reload pass. 15673 15674 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 15675 If defined, a C expression that returns nonzero for a CLASS for 15676 which a change from mode FROM to mode TO is invalid. 15677 15678 For the example, loading 32-bit integer or floating-point objects 15679 into floating-point registers on the Alpha extends them to 64 bits. 15680 Therefore loading a 64-bit object and then storing it as a 32-bit 15681 object does not store the low-order 32 bits, as would be the case 15682 for a normal register. Therefore, `alpha.h' defines 15683 `CANNOT_CHANGE_MODE_CLASS' as below: 15684 15685 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 15686 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 15687 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 15688 15689 Three other special macros describe which operands fit which 15690constraint letters. 15691 15692 -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C) 15693 A C expression that defines the machine-dependent operand 15694 constraint letters (`I', `J', `K', ... `P') that specify 15695 particular ranges of integer values. If C is one of those 15696 letters, the expression should check that VALUE, an integer, is in 15697 the appropriate range and return 1 if so, 0 otherwise. If C is 15698 not one of those letters, the value should be 0 regardless of 15699 VALUE. 15700 15701 -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 15702 Like `CONST_OK_FOR_LETTER_P', but you also get the constraint 15703 string passed in STR, so that you can use suffixes to distinguish 15704 between different variants. 15705 15706 -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C) 15707 A C expression that defines the machine-dependent operand 15708 constraint letters that specify particular ranges of 15709 `const_double' values (`G' or `H'). 15710 15711 If C is one of those letters, the expression should check that 15712 VALUE, an RTX of code `const_double', is in the appropriate range 15713 and return 1 if so, 0 otherwise. If C is not one of those 15714 letters, the value should be 0 regardless of VALUE. 15715 15716 `const_double' is used for all floating-point constants and for 15717 `DImode' fixed-point constants. A given letter can accept either 15718 or both kinds of values. It can use `GET_MODE' to distinguish 15719 between these kinds. 15720 15721 -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR) 15722 Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the 15723 constraint string passed in STR, so that you can use suffixes to 15724 distinguish between different variants. 15725 15726 -- Macro: EXTRA_CONSTRAINT (VALUE, C) 15727 A C expression that defines the optional machine-dependent 15728 constraint letters that can be used to segregate specific types of 15729 operands, usually memory references, for the target machine. Any 15730 letter that is not elsewhere defined and not matched by 15731 `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used. 15732 Normally this macro will not be defined. 15733 15734 If it is required for a particular target machine, it should 15735 return 1 if VALUE corresponds to the operand type represented by 15736 the constraint letter C. If C is not defined as an extra 15737 constraint, the value returned should be 0 regardless of VALUE. 15738 15739 For example, on the ROMP, load instructions cannot have their 15740 output in r0 if the memory reference contains a symbolic address. 15741 Constraint letter `Q' is defined as representing a memory address 15742 that does _not_ contain a symbolic address. An alternative is 15743 specified with a `Q' constraint on the input and `r' on the 15744 output. The next alternative specifies `m' on the input and a 15745 register class that does not include r0 on the output. 15746 15747 -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR) 15748 Like `EXTRA_CONSTRAINT', but you also get the constraint string 15749 passed in STR, so that you can use suffixes to distinguish between 15750 different variants. 15751 15752 -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR) 15753 A C expression that defines the optional machine-dependent 15754 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT', 15755 that should be treated like memory constraints by the reload pass. 15756 15757 It should return 1 if the operand type represented by the 15758 constraint at the start of STR, the first letter of which is the 15759 letter C, comprises a subset of all memory references including 15760 all those whose address is simply a base register. This allows 15761 the reload pass to reload an operand, if it does not directly 15762 correspond to the operand type of C, by copying its address into a 15763 base register. 15764 15765 For example, on the S/390, some instructions do not accept 15766 arbitrary memory references, but only those that do not make use 15767 of an index register. The constraint letter `Q' is defined via 15768 `EXTRA_CONSTRAINT' as representing a memory address of this type. 15769 If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q' 15770 constraint can handle any memory operand, because the reload pass 15771 knows it can be reloaded by copying the memory address into a base 15772 register if required. This is analogous to the way a `o' 15773 constraint can handle any memory operand. 15774 15775 -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR) 15776 A C expression that defines the optional machine-dependent 15777 constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' / 15778 `EXTRA_CONSTRAINT_STR', that should be treated like address 15779 constraints by the reload pass. 15780 15781 It should return 1 if the operand type represented by the 15782 constraint at the start of STR, which starts with the letter C, 15783 comprises a subset of all memory addresses including all those 15784 that consist of just a base register. This allows the reload pass 15785 to reload an operand, if it does not directly correspond to the 15786 operand type of STR, by copying it into a base register. 15787 15788 Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be 15789 used with the `address_operand' predicate. It is treated 15790 analogously to the `p' constraint. 15791 15792 15793File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 15794 1579511.10 Stack Layout and Calling Conventions 15796========================================== 15797 15798This describes the stack layout and calling conventions. 15799 15800* Menu: 15801 15802* Frame Layout:: 15803* Exception Handling:: 15804* Stack Checking:: 15805* Frame Registers:: 15806* Elimination:: 15807* Stack Arguments:: 15808* Register Arguments:: 15809* Scalar Return:: 15810* Aggregate Return:: 15811* Caller Saves:: 15812* Function Entry:: 15813* Profiling:: 15814* Tail Calls:: 15815 15816 15817File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 15818 1581911.10.1 Basic Stack Layout 15820-------------------------- 15821 15822Here is the basic stack layout. 15823 15824 -- Macro: STACK_GROWS_DOWNWARD 15825 Define this macro if pushing a word onto the stack moves the stack 15826 pointer to a smaller address. 15827 15828 When we say, "define this macro if ...," it means that the 15829 compiler checks this macro only with `#ifdef' so the precise 15830 definition used does not matter. 15831 15832 -- Macro: STACK_PUSH_CODE 15833 This macro defines the operation used when something is pushed on 15834 the stack. In RTL, a push operation will be `(set (mem 15835 (STACK_PUSH_CODE (reg sp))) ...)' 15836 15837 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'. 15838 Which of these is correct depends on the stack direction and on 15839 whether the stack pointer points to the last item on the stack or 15840 whether it points to the space for the next item on the stack. 15841 15842 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined, 15843 which is almost always right, and `PRE_INC' otherwise, which is 15844 often wrong. 15845 15846 -- Macro: FRAME_GROWS_DOWNWARD 15847 Define this macro if the addresses of local variable slots are at 15848 negative offsets from the frame pointer. 15849 15850 -- Macro: ARGS_GROW_DOWNWARD 15851 Define this macro if successive arguments to a function occupy 15852 decreasing addresses on the stack. 15853 15854 -- Macro: STARTING_FRAME_OFFSET 15855 Offset from the frame pointer to the first local variable slot to 15856 be allocated. 15857 15858 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by 15859 subtracting the first slot's length from `STARTING_FRAME_OFFSET'. 15860 Otherwise, it is found by adding the length of the first slot to 15861 the value `STARTING_FRAME_OFFSET'. 15862 15863 -- Macro: STACK_ALIGNMENT_NEEDED 15864 Define to zero to disable final alignment of the stack during 15865 reload. The nonzero default for this macro is suitable for most 15866 ports. 15867 15868 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there 15869 is a register save block following the local block that doesn't 15870 require alignment to `STACK_BOUNDARY', it may be beneficial to 15871 disable stack alignment and do it in the backend. 15872 15873 -- Macro: STACK_POINTER_OFFSET 15874 Offset from the stack pointer register to the first location at 15875 which outgoing arguments are placed. If not specified, the 15876 default value of zero is used. This is the proper value for most 15877 machines. 15878 15879 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 15880 the first location at which outgoing arguments are placed. 15881 15882 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 15883 Offset from the argument pointer register to the first argument's 15884 address. On some machines it may depend on the data type of the 15885 function. 15886 15887 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 15888 the first argument's address. 15889 15890 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 15891 Offset from the stack pointer register to an item dynamically 15892 allocated on the stack, e.g., by `alloca'. 15893 15894 The default value for this macro is `STACK_POINTER_OFFSET' plus the 15895 length of the outgoing arguments. The default is correct for most 15896 machines. See `function.c' for details. 15897 15898 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 15899 A C expression whose value is RTL representing the address in a 15900 stack frame where the pointer to the caller's frame is stored. 15901 Assume that FRAMEADDR is an RTL expression for the address of the 15902 stack frame itself. 15903 15904 If you don't define this macro, the default is to return the value 15905 of FRAMEADDR--that is, the stack frame address is also the address 15906 of the stack word that points to the previous frame. 15907 15908 -- Macro: SETUP_FRAME_ADDRESSES 15909 If defined, a C expression that produces the machine-specific code 15910 to setup the stack so that arbitrary frames can be accessed. For 15911 example, on the SPARC, we must flush all of the register windows 15912 to the stack before we can access arbitrary stack frames. You 15913 will seldom need to define this macro. 15914 15915 -- Macro: BUILTIN_SETJMP_FRAME_VALUE 15916 If defined, a C expression that contains an rtx that is used to 15917 store the address of the current frame into the built in `setjmp' 15918 buffer. The default value, `virtual_stack_vars_rtx', is correct 15919 for most machines. One reason you may need to define this macro 15920 is if `hard_frame_pointer_rtx' is the appropriate value on your 15921 machine. 15922 15923 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 15924 A C expression whose value is RTL representing the value of the 15925 return address for the frame COUNT steps up from the current 15926 frame, after the prologue. FRAMEADDR is the frame pointer of the 15927 COUNT frame, or the frame pointer of the COUNT - 1 frame if 15928 `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined. 15929 15930 The value of the expression must always be the correct address when 15931 COUNT is zero, but may be `NULL_RTX' if there is not way to 15932 determine the return address of other frames. 15933 15934 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 15935 Define this if the return address of a particular stack frame is 15936 accessed from the frame pointer of the previous stack frame. 15937 15938 -- Macro: INCOMING_RETURN_ADDR_RTX 15939 A C expression whose value is RTL representing the location of the 15940 incoming return address at the beginning of any function, before 15941 the prologue. This RTL is either a `REG', indicating that the 15942 return value is saved in `REG', or a `MEM' representing a location 15943 in the stack. 15944 15945 You only need to define this macro if you want to support call 15946 frame debugging information like that provided by DWARF 2. 15947 15948 If this RTL is a `REG', you should also define 15949 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'. 15950 15951 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 15952 A C expression whose value is an integer giving a DWARF 2 column 15953 number that may be used as an alternate return column. This should 15954 be defined only if `DWARF_FRAME_RETURN_COLUMN' is set to a general 15955 register, but an alternate column needs to be used for signal 15956 frames. 15957 15958 -- Macro: INCOMING_FRAME_SP_OFFSET 15959 A C expression whose value is an integer giving the offset, in 15960 bytes, from the value of the stack pointer register to the top of 15961 the stack frame at the beginning of any function, before the 15962 prologue. The top of the frame is defined to be the value of the 15963 stack pointer in the previous frame, just before the call 15964 instruction. 15965 15966 You only need to define this macro if you want to support call 15967 frame debugging information like that provided by DWARF 2. 15968 15969 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 15970 A C expression whose value is an integer giving the offset, in 15971 bytes, from the argument pointer to the canonical frame address 15972 (cfa). The final value should coincide with that calculated by 15973 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 15974 during virtual register instantiation. 15975 15976 The default value for this macro is `FIRST_PARM_OFFSET (fundecl)', 15977 which is correct for most machines; in general, the arguments are 15978 found immediately before the stack frame. Note that this is not 15979 the case on some targets that save registers into the caller's 15980 frame, such as SPARC and rs6000, and so such targets need to 15981 define this macro. 15982 15983 You only need to define this macro if the default is incorrect, 15984 and you want to support call frame debugging information like that 15985 provided by DWARF 2. 15986 15987 15988File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 15989 1599011.10.2 Exception Handling Support 15991---------------------------------- 15992 15993 -- Macro: EH_RETURN_DATA_REGNO (N) 15994 A C expression whose value is the Nth register number used for 15995 data by exception handlers, or `INVALID_REGNUM' if fewer than N 15996 registers are usable. 15997 15998 The exception handling library routines communicate with the 15999 exception handlers via a set of agreed upon registers. Ideally 16000 these registers should be call-clobbered; it is possible to use 16001 call-saved registers, but may negatively impact code size. The 16002 target must support at least 2 data registers, but should define 4 16003 if there are enough free registers. 16004 16005 You must define this macro if you want to support call frame 16006 exception handling like that provided by DWARF 2. 16007 16008 -- Macro: EH_RETURN_STACKADJ_RTX 16009 A C expression whose value is RTL representing a location in which 16010 to store a stack adjustment to be applied before function return. 16011 This is used to unwind the stack to an exception handler's call 16012 frame. It will be assigned zero on code paths that return 16013 normally. 16014 16015 Typically this is a call-clobbered hard register that is otherwise 16016 untouched by the epilogue, but could also be a stack slot. 16017 16018 Do not define this macro if the stack pointer is saved and restored 16019 by the regular prolog and epilog code in the call frame itself; in 16020 this case, the exception handling library routines will update the 16021 stack location to be restored in place. Otherwise, you must define 16022 this macro if you want to support call frame exception handling 16023 like that provided by DWARF 2. 16024 16025 -- Macro: EH_RETURN_HANDLER_RTX 16026 A C expression whose value is RTL representing a location in which 16027 to store the address of an exception handler to which we should 16028 return. It will not be assigned on code paths that return 16029 normally. 16030 16031 Typically this is the location in the call frame at which the 16032 normal return address is stored. For targets that return by 16033 popping an address off the stack, this might be a memory address 16034 just below the _target_ call frame rather than inside the current 16035 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already 16036 been assigned, so it may be used to calculate the location of the 16037 target call frame. 16038 16039 Some targets have more complex requirements than storing to an 16040 address calculable during initial code generation. In that case 16041 the `eh_return' instruction pattern should be used instead. 16042 16043 If you want to support call frame exception handling, you must 16044 define either this macro or the `eh_return' instruction pattern. 16045 16046 -- Macro: RETURN_ADDR_OFFSET 16047 If defined, an integer-valued C expression for which rtl will be 16048 generated to add it to the exception handler address before it is 16049 searched in the exception handling tables, and to subtract it 16050 again from the address before using it to return to the exception 16051 handler. 16052 16053 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 16054 This macro chooses the encoding of pointers embedded in the 16055 exception handling sections. If at all possible, this should be 16056 defined such that the exception handling section will not require 16057 dynamic relocations, and so may be read-only. 16058 16059 CODE is 0 for data, 1 for code labels, 2 for function pointers. 16060 GLOBAL is true if the symbol may be affected by dynamic 16061 relocations. The macro should return a combination of the 16062 `DW_EH_PE_*' defines as found in `dwarf2.h'. 16063 16064 If this macro is not defined, pointers will not be encoded but 16065 represented directly. 16066 16067 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 16068 ADDR, DONE) 16069 This macro allows the target to emit whatever special magic is 16070 required to represent the encoding chosen by 16071 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 16072 pc-relative and indirect encodings; this must be defined if the 16073 target uses text-relative or data-relative encodings. 16074 16075 This is a C statement that branches to DONE if the format was 16076 handled. ENCODING is the format chosen, SIZE is the number of 16077 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be 16078 emitted. 16079 16080 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS, SUCCESS) 16081 This macro allows the target to add cpu and operating system 16082 specific code to the call-frame unwinder for use when there is no 16083 unwind data available. The most common reason to implement this 16084 macro is to unwind through signal frames. 16085 16086 This macro is called from `uw_frame_state_for' in `unwind-dw2.c' 16087 and `unwind-ia64.c'. CONTEXT is an `_Unwind_Context'; FS is an 16088 `_Unwind_FrameState'. Examine `context->ra' for the address of 16089 the code being executed and `context->cfa' for the stack pointer 16090 value. If the frame can be decoded, the register save addresses 16091 should be updated in FS and the macro should branch to SUCCESS. 16092 If the frame cannot be decoded, the macro should do nothing. 16093 16094 For proper signal handling in Java this macro is accompanied by 16095 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h' 16096 headers. 16097 16098 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 16099 This macro allows the target to add operating system specific code 16100 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding 16101 directive, usually used for signal or interrupt frames. 16102 16103 This macro is called from `uw_update_context' in `unwind-ia64.c'. 16104 CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'. 16105 Examine `fs->unwabi' for the abi and context in the `.unwabi' 16106 directive. If the `.unwabi' directive can be handled, the 16107 register save addresses should be updated in FS. 16108 16109 16110File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 16111 1611211.10.3 Specifying How Stack Checking is Done 16113--------------------------------------------- 16114 16115GCC will check that stack references are within the boundaries of the 16116stack, if the `-fstack-check' is specified, in one of three ways: 16117 16118 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC 16119 will assume that you have arranged for stack checking to be done at 16120 appropriate places in the configuration files, e.g., in 16121 `TARGET_ASM_FUNCTION_PROLOGUE'. GCC will do not other special 16122 processing. 16123 16124 2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern 16125 called `check_stack' in your `md' file, GCC will call that pattern 16126 with one argument which is the address to compare the stack value 16127 against. You must arrange for this pattern to report an error if 16128 the stack pointer is out of range. 16129 16130 3. If neither of the above are true, GCC will generate code to 16131 periodically "probe" the stack pointer using the values of the 16132 macros defined below. 16133 16134 Normally, you will use the default values of these macros, so GCC 16135will use the third approach. 16136 16137 -- Macro: STACK_CHECK_BUILTIN 16138 A nonzero value if stack checking is done by the configuration 16139 files in a machine-dependent manner. You should define this macro 16140 if stack checking is require by the ABI of your machine or if you 16141 would like to have to stack checking in some more efficient way 16142 than GCC's portable approach. The default value of this macro is 16143 zero. 16144 16145 -- Macro: STACK_CHECK_PROBE_INTERVAL 16146 An integer representing the interval at which GCC must generate 16147 stack probe instructions. You will normally define this macro to 16148 be no larger than the size of the "guard pages" at the end of a 16149 stack area. The default value of 4096 is suitable for most 16150 systems. 16151 16152 -- Macro: STACK_CHECK_PROBE_LOAD 16153 A integer which is nonzero if GCC should perform the stack probe 16154 as a load instruction and zero if GCC should use a store 16155 instruction. The default is zero, which is the most efficient 16156 choice on most systems. 16157 16158 -- Macro: STACK_CHECK_PROTECT 16159 The number of bytes of stack needed to recover from a stack 16160 overflow, for languages where such a recovery is supported. The 16161 default value of 75 words should be adequate for most machines. 16162 16163 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 16164 The maximum size of a stack frame, in bytes. GCC will generate 16165 probe instructions in non-leaf functions to ensure at least this 16166 many bytes of stack are available. If a stack frame is larger 16167 than this size, stack checking will not be reliable and GCC will 16168 issue a warning. The default is chosen so that GCC only generates 16169 one instruction on most systems. You should normally not change 16170 the default value of this macro. 16171 16172 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 16173 GCC uses this value to generate the above warning message. It 16174 represents the amount of fixed frame used by a function, not 16175 including space for any callee-saved registers, temporaries and 16176 user variables. You need only specify an upper bound for this 16177 amount and will normally use the default of four words. 16178 16179 -- Macro: STACK_CHECK_MAX_VAR_SIZE 16180 The maximum size, in bytes, of an object that GCC will place in the 16181 fixed area of the stack frame when the user specifies 16182 `-fstack-check'. GCC computed the default from the values of the 16183 above macros and you will normally not need to override that 16184 default. 16185 16186 16187File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 16188 1618911.10.4 Registers That Address the Stack Frame 16190---------------------------------------------- 16191 16192This discusses registers that address the stack frame. 16193 16194 -- Macro: STACK_POINTER_REGNUM 16195 The register number of the stack pointer register, which must also 16196 be a fixed register according to `FIXED_REGISTERS'. On most 16197 machines, the hardware determines which register this is. 16198 16199 -- Macro: FRAME_POINTER_REGNUM 16200 The register number of the frame pointer register, which is used to 16201 access automatic variables in the stack frame. On some machines, 16202 the hardware determines which register this is. On other 16203 machines, you can choose any register you wish for this purpose. 16204 16205 -- Macro: HARD_FRAME_POINTER_REGNUM 16206 On some machines the offset between the frame pointer and starting 16207 offset of the automatic variables is not known until after register 16208 allocation has been done (for example, because the saved registers 16209 are between these two locations). On those machines, define 16210 `FRAME_POINTER_REGNUM' the number of a special, fixed register to 16211 be used internally until the offset is known, and define 16212 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 16213 used for the frame pointer. 16214 16215 You should define this macro only in the very rare circumstances 16216 when it is not possible to calculate the offset between the frame 16217 pointer and the automatic variables until after register 16218 allocation has been completed. When this macro is defined, you 16219 must also indicate in your definition of `ELIMINABLE_REGS' how to 16220 eliminate `FRAME_POINTER_REGNUM' into either 16221 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. 16222 16223 Do not define this macro if it would be the same as 16224 `FRAME_POINTER_REGNUM'. 16225 16226 -- Macro: ARG_POINTER_REGNUM 16227 The register number of the arg pointer register, which is used to 16228 access the function's argument list. On some machines, this is 16229 the same as the frame pointer register. On some machines, the 16230 hardware determines which register this is. On other machines, 16231 you can choose any register you wish for this purpose. If this is 16232 not the same register as the frame pointer register, then you must 16233 mark it as a fixed register according to `FIXED_REGISTERS', or 16234 arrange to be able to eliminate it (*note Elimination::). 16235 16236 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 16237 The register number of the return address pointer register, which 16238 is used to access the current function's return address from the 16239 stack. On some machines, the return address is not at a fixed 16240 offset from the frame pointer or stack pointer or argument 16241 pointer. This register can be defined to point to the return 16242 address on the stack, and then be converted by `ELIMINABLE_REGS' 16243 into either the frame pointer or stack pointer. 16244 16245 Do not define this macro unless there is no other way to get the 16246 return address from the stack. 16247 16248 -- Macro: STATIC_CHAIN_REGNUM 16249 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 16250 Register numbers used for passing a function's static chain 16251 pointer. If register windows are used, the register number as 16252 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', 16253 while the register number as seen by the calling function is 16254 `STATIC_CHAIN_REGNUM'. If these registers are the same, 16255 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 16256 16257 The static chain register need not be a fixed register. 16258 16259 If the static chain is passed in memory, these macros should not be 16260 defined; instead, the next two macros should be defined. 16261 16262 -- Macro: STATIC_CHAIN 16263 -- Macro: STATIC_CHAIN_INCOMING 16264 If the static chain is passed in memory, these macros provide rtx 16265 giving `mem' expressions that denote where they are stored. 16266 `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as 16267 seen by the calling and called functions, respectively. Often the 16268 former will be at an offset from the stack pointer and the latter 16269 at an offset from the frame pointer. 16270 16271 The variables `stack_pointer_rtx', `frame_pointer_rtx', and 16272 `arg_pointer_rtx' will have been initialized prior to the use of 16273 these macros and should be used to refer to those items. 16274 16275 If the static chain is passed in a register, the two previous 16276 macros should be defined instead. 16277 16278 -- Macro: DWARF_FRAME_REGISTERS 16279 This macro specifies the maximum number of hard registers that can 16280 be saved in a call frame. This is used to size data structures 16281 used in DWARF2 exception handling. 16282 16283 Prior to GCC 3.0, this macro was needed in order to establish a 16284 stable exception handling ABI in the face of adding new hard 16285 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 16286 insulated from changes in the number of hard registers. 16287 Nevertheless, this macro can still be used to reduce the runtime 16288 memory requirements of the exception handling routines, which can 16289 be substantial if the ISA contains a lot of registers that are not 16290 call-saved. 16291 16292 If this macro is not defined, it defaults to 16293 `FIRST_PSEUDO_REGISTER'. 16294 16295 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 16296 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided 16297 for backward compatibility in pre GCC 3.0 compiled code. 16298 16299 If this macro is not defined, it defaults to 16300 `DWARF_FRAME_REGISTERS'. 16301 16302 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 16303 Define this macro if the target's representation for dwarf 16304 registers is different than the internal representation for unwind 16305 column. Given a dwarf register, this macro should return the 16306 internal unwind column number to use instead. 16307 16308 See the PowerPC's SPE target for an example. 16309 16310 -- Macro: DWARF_FRAME_REGNUM (REGNO) 16311 Define this macro if the target's representation for dwarf 16312 registers used in .eh_frame or .debug_frame is different from that 16313 used in other debug info sections. Given a GCC hard register 16314 number, this macro should return the .eh_frame register number. 16315 The default is `DBX_REGISTER_NUMBER (REGNO)'. 16316 16317 16318 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 16319 Define this macro to map register numbers held in the call frame 16320 info that GCC has collected using `DWARF_FRAME_REGNUM' to those 16321 that should be output in .debug_frame (`FOR_EH' is zero) and 16322 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'. 16323 16324 16325 16326File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 16327 1632811.10.5 Eliminating Frame Pointer and Arg Pointer 16329------------------------------------------------- 16330 16331This is about eliminating the frame pointer and arg pointer. 16332 16333 -- Macro: FRAME_POINTER_REQUIRED 16334 A C expression which is nonzero if a function must have and use a 16335 frame pointer. This expression is evaluated in the reload pass. 16336 If its value is nonzero the function will have a frame pointer. 16337 16338 The expression can in principle examine the current function and 16339 decide according to the facts, but on most machines the constant 0 16340 or the constant 1 suffices. Use 0 when the machine allows code to 16341 be generated with no frame pointer, and doing so saves some time 16342 or space. Use 1 when there is no possible advantage to avoiding a 16343 frame pointer. 16344 16345 In certain cases, the compiler does not know how to produce valid 16346 code without a frame pointer. The compiler recognizes those cases 16347 and automatically gives the function a frame pointer regardless of 16348 what `FRAME_POINTER_REQUIRED' says. You don't need to worry about 16349 them. 16350 16351 In a function that does not require a frame pointer, the frame 16352 pointer register can be allocated for ordinary usage, unless you 16353 mark it as a fixed register. See `FIXED_REGISTERS' for more 16354 information. 16355 16356 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 16357 A C statement to store in the variable DEPTH-VAR the difference 16358 between the frame pointer and the stack pointer values immediately 16359 after the function prologue. The value would be computed from 16360 information such as the result of `get_frame_size ()' and the 16361 tables of registers `regs_ever_live' and `call_used_regs'. 16362 16363 If `ELIMINABLE_REGS' is defined, this macro will be not be used and 16364 need not be defined. Otherwise, it must be defined even if 16365 `FRAME_POINTER_REQUIRED' is defined to always be true; in that 16366 case, you may set DEPTH-VAR to anything. 16367 16368 -- Macro: ELIMINABLE_REGS 16369 If defined, this macro specifies a table of register pairs used to 16370 eliminate unneeded registers that point into the stack frame. If 16371 it is not defined, the only elimination attempted by the compiler 16372 is to replace references to the frame pointer with references to 16373 the stack pointer. 16374 16375 The definition of this macro is a list of structure 16376 initializations, each of which specifies an original and 16377 replacement register. 16378 16379 On some machines, the position of the argument pointer is not 16380 known until the compilation is completed. In such a case, a 16381 separate hard register must be used for the argument pointer. 16382 This register can be eliminated by replacing it with either the 16383 frame pointer or the argument pointer, depending on whether or not 16384 the frame pointer has been eliminated. 16385 16386 In this case, you might specify: 16387 #define ELIMINABLE_REGS \ 16388 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 16389 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 16390 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 16391 16392 Note that the elimination of the argument pointer with the stack 16393 pointer is specified first since that is the preferred elimination. 16394 16395 -- Macro: CAN_ELIMINATE (FROM-REG, TO-REG) 16396 A C expression that returns nonzero if the compiler is allowed to 16397 try to replace register number FROM-REG with register number 16398 TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is 16399 defined, and will usually be the constant 1, since most of the 16400 cases preventing register elimination are things that the compiler 16401 already knows about. 16402 16403 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 16404 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 16405 specifies the initial difference between the specified pair of 16406 registers. This macro must be defined if `ELIMINABLE_REGS' is 16407 defined. 16408 16409 16410File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 16411 1641211.10.6 Passing Function Arguments on the Stack 16413----------------------------------------------- 16414 16415The macros in this section control how arguments are passed on the 16416stack. See the following section for other macros that control passing 16417certain arguments in registers. 16418 16419 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (tree FNTYPE) 16420 This target hook returns `true' if an argument declared in a 16421 prototype as an integral type smaller than `int' should actually be 16422 passed as an `int'. In addition to avoiding errors in certain 16423 cases of mismatch, it also makes for better code on certain 16424 machines. The default is to not promote prototypes. 16425 16426 -- Macro: PUSH_ARGS 16427 A C expression. If nonzero, push insns will be used to pass 16428 outgoing arguments. If the target machine does not have a push 16429 instruction, set it to zero. That directs GCC to use an alternate 16430 strategy: to allocate the entire argument block and then store the 16431 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING' 16432 must be defined too. 16433 16434 -- Macro: PUSH_ARGS_REVERSED 16435 A C expression. If nonzero, function arguments will be evaluated 16436 from last to first, rather than from first to last. If this macro 16437 is not defined, it defaults to `PUSH_ARGS' on targets where the 16438 stack and args grow in opposite directions, and 0 otherwise. 16439 16440 -- Macro: PUSH_ROUNDING (NPUSHED) 16441 A C expression that is the number of bytes actually pushed onto the 16442 stack when an instruction attempts to push NPUSHED bytes. 16443 16444 On some machines, the definition 16445 16446 #define PUSH_ROUNDING(BYTES) (BYTES) 16447 16448 will suffice. But on other machines, instructions that appear to 16449 push one byte actually push two bytes in an attempt to maintain 16450 alignment. Then the definition should be 16451 16452 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 16453 16454 -- Macro: ACCUMULATE_OUTGOING_ARGS 16455 A C expression. If nonzero, the maximum amount of space required 16456 for outgoing arguments will be computed and placed into the 16457 variable `current_function_outgoing_args_size'. No space will be 16458 pushed onto the stack for each call; instead, the function 16459 prologue should increase the stack frame size by this amount. 16460 16461 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not 16462 proper. 16463 16464 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 16465 Define this macro if functions should assume that stack space has 16466 been allocated for arguments even when their values are passed in 16467 registers. 16468 16469 The value of this macro is the size, in bytes, of the area 16470 reserved for arguments passed in registers for the function 16471 represented by FNDECL, which can be zero if GCC is calling a 16472 library function. 16473 16474 This space can be allocated by the caller, or be a part of the 16475 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says 16476 which. 16477 16478 -- Macro: MAYBE_REG_PARM_STACK_SPACE 16479 -- Macro: FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE) 16480 Define these macros in addition to the one above if functions might 16481 allocate stack space for arguments even when their values are 16482 passed in registers. These should be used when the stack space 16483 allocated for arguments in registers is not a simple constant 16484 independent of the function declaration. 16485 16486 The value of the first macro is the size, in bytes, of the area 16487 that we should initially assume would be reserved for arguments 16488 passed in registers. 16489 16490 The value of the second macro is the actual size, in bytes, of the 16491 area that will be reserved for arguments passed in registers. 16492 This takes two arguments: an integer representing the number of 16493 bytes of fixed sized arguments on the stack, and a tree 16494 representing the number of bytes of variable sized arguments on 16495 the stack. 16496 16497 When these macros are defined, `REG_PARM_STACK_SPACE' will only be 16498 called for libcall functions, the current function, or for a 16499 function being called when it is known that such stack space must 16500 be allocated. In each case this value can be easily computed. 16501 16502 When deciding whether a called function needs such stack space, 16503 and how much space to reserve, GCC uses these two macros instead of 16504 `REG_PARM_STACK_SPACE'. 16505 16506 -- Macro: OUTGOING_REG_PARM_STACK_SPACE 16507 Define this if it is the responsibility of the caller to allocate 16508 the area reserved for arguments passed in registers. 16509 16510 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 16511 whether the space for these arguments counts in the value of 16512 `current_function_outgoing_args_size'. 16513 16514 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 16515 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the 16516 stack parameters don't skip the area specified by it. 16517 16518 Normally, when a parameter is not passed in registers, it is 16519 placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 16520 Defining this macro suppresses this behavior and causes the 16521 parameter to be passed on the stack in its natural location. 16522 16523 -- Macro: RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE) 16524 A C expression that should indicate the number of bytes of its own 16525 arguments that a function pops on returning, or 0 if the function 16526 pops no arguments and the caller must therefore pop them all after 16527 the function returns. 16528 16529 FUNDECL is a C variable whose value is a tree node that describes 16530 the function in question. Normally it is a node of type 16531 `FUNCTION_DECL' that describes the declaration of the function. 16532 From this you can obtain the `DECL_ATTRIBUTES' of the function. 16533 16534 FUNTYPE is a C variable whose value is a tree node that describes 16535 the function in question. Normally it is a node of type 16536 `FUNCTION_TYPE' that describes the data type of the function. 16537 From this it is possible to obtain the data types of the value and 16538 arguments (if known). 16539 16540 When a call to a library function is being considered, FUNDECL 16541 will contain an identifier node for the library function. Thus, if 16542 you need to distinguish among various library functions, you can 16543 do so by their names. Note that "library function" in this 16544 context means a function used to perform arithmetic, whose name is 16545 known specially in the compiler and was not mentioned in the C 16546 code being compiled. 16547 16548 STACK-SIZE is the number of bytes of arguments passed on the 16549 stack. If a variable number of bytes is passed, it is zero, and 16550 argument popping will always be the responsibility of the calling 16551 function. 16552 16553 On the VAX, all functions always pop their arguments, so the 16554 definition of this macro is STACK-SIZE. On the 68000, using the 16555 standard calling convention, no functions pop their arguments, so 16556 the value of the macro is always 0 in this case. But an 16557 alternative calling convention is available in which functions 16558 that take a fixed number of arguments pop them but other functions 16559 (such as `printf') pop nothing (the caller pops all). When this 16560 convention is in use, FUNTYPE is examined to determine whether a 16561 function takes a fixed number of arguments. 16562 16563 -- Macro: CALL_POPS_ARGS (CUM) 16564 A C expression that should indicate the number of bytes a call 16565 sequence pops off the stack. It is added to the value of 16566 `RETURN_POPS_ARGS' when compiling a function call. 16567 16568 CUM is the variable in which all arguments to the called function 16569 have been accumulated. 16570 16571 On certain architectures, such as the SH5, a call trampoline is 16572 used that pops certain registers off the stack, depending on the 16573 arguments that have been passed to the function. Since this is a 16574 property of the call site, not of the called function, 16575 `RETURN_POPS_ARGS' is not appropriate. 16576 16577 16578File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 16579 1658011.10.7 Passing Arguments in Registers 16581-------------------------------------- 16582 16583This section describes the macros which let you control how various 16584types of arguments are passed in registers or how they are arranged in 16585the stack. 16586 16587 -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED) 16588 A C expression that controls whether a function argument is passed 16589 in a register, and which register. 16590 16591 The arguments are CUM, which summarizes all the previous 16592 arguments; MODE, the machine mode of the argument; TYPE, the data 16593 type of the argument as a tree node or 0 if that is not known 16594 (which happens for C support library functions); and NAMED, which 16595 is 1 for an ordinary argument and 0 for nameless arguments that 16596 correspond to `...' in the called function's prototype. TYPE can 16597 be an incomplete type if a syntax error has previously occurred. 16598 16599 The value of the expression is usually either a `reg' RTX for the 16600 hard register in which to pass the argument, or zero to pass the 16601 argument on the stack. 16602 16603 For machines like the VAX and 68000, where normally all arguments 16604 are pushed, zero suffices as a definition. 16605 16606 The value of the expression can also be a `parallel' RTX. This is 16607 used when an argument is passed in multiple locations. The mode 16608 of the `parallel' should be the mode of the entire argument. The 16609 `parallel' holds any number of `expr_list' pairs; each one 16610 describes where part of the argument is passed. In each 16611 `expr_list' the first operand must be a `reg' RTX for the hard 16612 register in which to pass this part of the argument, and the mode 16613 of the register RTX indicates how large this part of the argument 16614 is. The second operand of the `expr_list' is a `const_int' which 16615 gives the offset in bytes into the entire argument of where this 16616 part starts. As a special exception the first `expr_list' in the 16617 `parallel' RTX may have a first operand of zero. This indicates 16618 that the entire argument is also stored on the stack. 16619 16620 The last time this macro is called, it is called with `MODE == 16621 VOIDmode', and its result is passed to the `call' or `call_value' 16622 pattern as operands 2 and 3 respectively. 16623 16624 The usual way to make the ISO library `stdarg.h' work on a machine 16625 where some arguments are usually passed in registers, is to cause 16626 nameless arguments to be passed on the stack instead. This is done 16627 by making `FUNCTION_ARG' return 0 whenever NAMED is 0. 16628 16629 You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the 16630 definition of this macro to determine if this argument is of a 16631 type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 16632 is not defined and `FUNCTION_ARG' returns nonzero for such an 16633 argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 16634 defined, the argument will be computed in the stack and then 16635 loaded into a register. 16636 16637 -- Macro: MUST_PASS_IN_STACK (MODE, TYPE) 16638 Define as a C expression that evaluates to nonzero if we do not 16639 know how to pass TYPE solely in registers. The file `expr.h' 16640 defines a definition that is usually appropriate, refer to 16641 `expr.h' for additional documentation. 16642 16643 -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED) 16644 Define this macro if the target machine has "register windows", so 16645 that the register in which a function sees an arguments is not 16646 necessarily the same as the one in which the caller passed the 16647 argument. 16648 16649 For such machines, `FUNCTION_ARG' computes the register in which 16650 the caller passes the value, and `FUNCTION_INCOMING_ARG' should be 16651 defined in a similar fashion to tell the function being called 16652 where the arguments will arrive. 16653 16654 If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves 16655 both purposes. 16656 16657 -- Macro: FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED) 16658 A C expression for the number of words, at the beginning of an 16659 argument, that must be put in registers. The value must be zero 16660 for arguments that are passed entirely in registers or that are 16661 entirely pushed on the stack. 16662 16663 On some machines, certain arguments must be passed partially in 16664 registers and partially in memory. On these machines, typically 16665 the first N words of arguments are passed in registers, and the 16666 rest on the stack. If a multi-word argument (a `double' or a 16667 structure) crosses that boundary, its first few words must be 16668 passed in registers and the rest must be pushed. This macro tells 16669 the compiler when this occurs, and how many of the words should go 16670 in registers. 16671 16672 `FUNCTION_ARG' for these arguments should return the first 16673 register to be used by the caller for this argument; likewise 16674 `FUNCTION_INCOMING_ARG', for the called function. 16675 16676 -- Macro: FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED) 16677 A C expression that indicates when an argument must be passed by 16678 reference. If nonzero for an argument, a copy of that argument is 16679 made in memory and a pointer to the argument is passed instead of 16680 the argument itself. The pointer is passed in whatever way is 16681 appropriate for passing a pointer to that type. 16682 16683 On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable 16684 definition of this macro might be 16685 #define FUNCTION_ARG_PASS_BY_REFERENCE\ 16686 (CUM, MODE, TYPE, NAMED) \ 16687 MUST_PASS_IN_STACK (MODE, TYPE) 16688 16689 -- Macro: FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED) 16690 If defined, a C expression that indicates when it is the called 16691 function's responsibility to make a copy of arguments passed by 16692 invisible reference. Normally, the caller makes a copy and passes 16693 the address of the copy to the routine being called. When 16694 `FUNCTION_ARG_CALLEE_COPIES' is defined and is nonzero, the caller 16695 does not make a copy. Instead, it passes a pointer to the "live" 16696 value. The called function must not modify this value. If it can 16697 be determined that the value won't be modified, it need not make a 16698 copy; otherwise a copy must be made. 16699 16700 -- Macro: CUMULATIVE_ARGS 16701 A C type for declaring a variable that is used as the first 16702 argument of `FUNCTION_ARG' and other related values. For some 16703 target machines, the type `int' suffices and can hold the number 16704 of bytes of argument so far. 16705 16706 There is no need to record in `CUMULATIVE_ARGS' anything about the 16707 arguments that have been passed on the stack. The compiler has 16708 other variables to keep track of that. For target machines on 16709 which all arguments are passed on the stack, there is no need to 16710 store anything in `CUMULATIVE_ARGS'; however, the data structure 16711 must exist and should not be empty, so use `int'. 16712 16713 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 16714 N_NAMED_ARGS) 16715 A C statement (sans semicolon) for initializing the variable CUM 16716 for the state at the beginning of the argument list. The variable 16717 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 16718 for the data type of the function which will receive the args, or 16719 0 if the args are to a compiler support library function. For 16720 direct calls that are not libcalls, FNDECL contain the declaration 16721 node of the function. FNDECL is also set when 16722 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function 16723 being compiled. N_NAMED_ARGS is set to the number of named 16724 arguments, including a structure return address if it is passed as 16725 a parameter, when making a call. When processing incoming 16726 arguments, N_NAMED_ARGS is set to -1. 16727 16728 When processing a call to a compiler support library function, 16729 LIBNAME identifies which one. It is a `symbol_ref' rtx which 16730 contains the name of the function, as a string. LIBNAME is 0 when 16731 an ordinary C function call is being processed. Thus, each time 16732 this macro is called, either LIBNAME or FNTYPE is nonzero, but 16733 never both of them at once. 16734 16735 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 16736 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, 16737 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'. 16738 INDIRECT would always be zero, too. If this macro is not 16739 defined, `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is 16740 used instead. 16741 16742 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 16743 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 16744 finding the arguments for the function being compiled. If this 16745 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 16746 16747 The value passed for LIBNAME is always 0, since library routines 16748 with special calling conventions are never compiled with GCC. The 16749 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'. 16750 16751 -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED) 16752 A C statement (sans semicolon) to update the summarizer variable 16753 CUM to advance past an argument in the argument list. The values 16754 MODE, TYPE and NAMED describe that argument. Once this is done, 16755 the variable CUM is suitable for analyzing the _following_ 16756 argument with `FUNCTION_ARG', etc. 16757 16758 This macro need not do anything if the argument in question was 16759 passed on the stack. The compiler knows how to track the amount 16760 of stack space used for arguments without any special help. 16761 16762 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 16763 If defined, a C expression which determines whether, and in which 16764 direction, to pad out an argument with extra space. The value 16765 should be of type `enum direction': either `upward' to pad above 16766 the argument, `downward' to pad below, or `none' to inhibit 16767 padding. 16768 16769 The _amount_ of padding is always just enough to reach the next 16770 multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control 16771 it. 16772 16773 This macro has a default definition which is right for most 16774 systems. For little-endian machines, the default is to pad 16775 upward. For big-endian machines, the default is to pad downward 16776 for an argument of constant size shorter than an `int', and upward 16777 otherwise. 16778 16779 -- Macro: PAD_VARARGS_DOWN 16780 If defined, a C expression which determines whether the default 16781 implementation of va_arg will attempt to pad down before reading 16782 the next argument, if that argument is smaller than its aligned 16783 space as controlled by `PARM_BOUNDARY'. If this macro is not 16784 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN' 16785 is true. 16786 16787 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 16788 Specify padding for the last element of a block move between 16789 registers and memory. FIRST is nonzero if this is the only 16790 element. Defining this macro allows better control of register 16791 function parameters on big-endian machines, without using 16792 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test 16793 padding and mode of types in registers, as there is no longer a 16794 "wrong" part of a register; For example, a three byte aggregate 16795 may be passed in the high part of a register if so required. 16796 16797 -- Macro: FUNCTION_ARG_BOUNDARY (MODE, TYPE) 16798 If defined, a C expression that gives the alignment boundary, in 16799 bits, of an argument with the specified mode and type. If it is 16800 not defined, `PARM_BOUNDARY' is used for all arguments. 16801 16802 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 16803 A C expression that is nonzero if REGNO is the number of a hard 16804 register in which function arguments are sometimes passed. This 16805 does _not_ include implicit arguments such as the static chain and 16806 the structure-value address. On many machines, no registers can be 16807 used for this purpose since all function arguments are pushed on 16808 the stack. 16809 16810 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (tree TYPE) 16811 This hook should return true if parameter of type TYPE are passed 16812 as two scalar parameters. By default, GCC will attempt to pack 16813 complex arguments into the target's word size. Some ABIs require 16814 complex arguments to be split and treated as their individual 16815 components. For example, on AIX64, complex floats should be 16816 passed in a pair of floating point registers, even though a 16817 complex float would fit in one 64-bit floating point register. 16818 16819 The default value of this hook is `NULL', which is treated as 16820 always false. 16821 16822 16823File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 16824 1682511.10.8 How Scalar Function Values Are Returned 16826----------------------------------------------- 16827 16828This section discusses the macros that control returning scalars as 16829values--values that can fit in registers. 16830 16831 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 16832 A C expression to create an RTX representing the place where a 16833 function returns a value of data type VALTYPE. VALTYPE is a tree 16834 node representing a data type. Write `TYPE_MODE (VALTYPE)' to get 16835 the machine mode used to represent that type. On many machines, 16836 only the mode is relevant. (Actually, on most machines, scalar 16837 values are returned in the same place regardless of mode). 16838 16839 The value of the expression is usually a `reg' RTX for the hard 16840 register where the return value is stored. The value can also be a 16841 `parallel' RTX, if the return value is in multiple places. See 16842 `FUNCTION_ARG' for an explanation of the `parallel' form. 16843 16844 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 16845 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is 16846 a scalar type. 16847 16848 If the precise function being called is known, FUNC is a tree node 16849 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 16850 makes it possible to use a different value-returning convention 16851 for specific functions when all their calls are known. 16852 16853 `FUNCTION_VALUE' is not used for return vales with aggregate data 16854 types, because these are returned in another way. See 16855 `TARGET_STRUCT_VALUE_RTX' and related macros, below. 16856 16857 -- Macro: FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC) 16858 Define this macro if the target machine has "register windows" so 16859 that the register in which a function returns its value is not the 16860 same as the one in which the caller sees the value. 16861 16862 For such machines, `FUNCTION_VALUE' computes the register in which 16863 the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be 16864 defined in a similar fashion to tell the function where to put the 16865 value. 16866 16867 If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' 16868 serves both purposes. 16869 16870 `FUNCTION_OUTGOING_VALUE' is not used for return vales with 16871 aggregate data types, because these are returned in another way. 16872 See `TARGET_STRUCT_VALUE_RTX' and related macros, below. 16873 16874 -- Macro: LIBCALL_VALUE (MODE) 16875 A C expression to create an RTX representing the place where a 16876 library function returns a value of mode MODE. If the precise 16877 function being called is known, FUNC is a tree node 16878 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 16879 makes it possible to use a different value-returning convention 16880 for specific functions when all their calls are known. 16881 16882 Note that "library function" in this context means a compiler 16883 support routine, used to perform arithmetic, whose name is known 16884 specially by the compiler and was not mentioned in the C code being 16885 compiled. 16886 16887 The definition of `LIBRARY_VALUE' need not be concerned aggregate 16888 data types, because none of the library functions returns such 16889 types. 16890 16891 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 16892 A C expression that is nonzero if REGNO is the number of a hard 16893 register in which the values of called function may come back. 16894 16895 A register whose use for returning values is limited to serving as 16896 the second of a pair (for a value of type `double', say) need not 16897 be recognized by this macro. So for most machines, this definition 16898 suffices: 16899 16900 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 16901 16902 If the machine has register windows, so that the caller and the 16903 called function use different registers for the return value, this 16904 macro should recognize only the caller's register numbers. 16905 16906 -- Macro: APPLY_RESULT_SIZE 16907 Define this macro if `untyped_call' and `untyped_return' need more 16908 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and 16909 restoring an arbitrary return value. 16910 16911 -- Target Hook: bool TARGET_RETURN_IN_MSB (tree TYPE) 16912 This hook should return true if values of type TYPE are returned 16913 at the most significant end of a register (in other words, if they 16914 are padded at the least significant end). You can assume that TYPE 16915 is returned in a register; the caller is required to check this. 16916 16917 Note that the register provided by `FUNCTION_VALUE' must be able 16918 to hold the complete return value. For example, if a 1-, 2- or 16919 3-byte structure is returned at the most significant end of a 16920 4-byte register, `FUNCTION_VALUE' should provide an `SImode' rtx. 16921 16922 16923File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 16924 1692511.10.9 How Large Values Are Returned 16926------------------------------------- 16927 16928When a function value's mode is `BLKmode' (and in some other cases), 16929the value is not returned according to `FUNCTION_VALUE' (*note Scalar 16930Return::). Instead, the caller passes the address of a block of memory 16931in which the value should be stored. This address is called the 16932"structure value address". 16933 16934 This section describes how to control returning structure values in 16935memory. 16936 16937 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE) 16938 This target hook should return a nonzero value to say to return the 16939 function value in memory, just as large structures are always 16940 returned. Here TYPE will be the data type of the value, and FNTYPE 16941 will be the type of the function doing the returning, or `NULL' for 16942 libcalls. 16943 16944 Note that values of mode `BLKmode' must be explicitly handled by 16945 this function. Also, the option `-fpcc-struct-return' takes 16946 effect regardless of this macro. On most systems, it is possible 16947 to leave the hook undefined; this causes a default definition to 16948 be used, whose value is the constant 1 for `BLKmode' values, and 0 16949 otherwise. 16950 16951 Do not use this hook to indicate that structures and unions should 16952 always be returned in memory. You should instead use 16953 `DEFAULT_PCC_STRUCT_RETURN' to indicate this. 16954 16955 -- Macro: DEFAULT_PCC_STRUCT_RETURN 16956 Define this macro to be 1 if all structure and union return values 16957 must be in memory. Since this results in slower code, this should 16958 be defined only if needed for compatibility with other compilers 16959 or with an ABI. If you define this macro to be 0, then the 16960 conventions used for structure and union return values are decided 16961 by the `TARGET_RETURN_IN_MEMORY' target hook. 16962 16963 If not defined, this defaults to the value 1. 16964 16965 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 16966 This target hook should return the location of the structure value 16967 address (normally a `mem' or `reg'), or 0 if the address is passed 16968 as an "invisible" first argument. Note that FNDECL may be `NULL', 16969 for libcalls. 16970 16971 On some architectures the place where the structure value address 16972 is found by the called function is not the same place that the 16973 caller put it. This can be due to register windows, or it could 16974 be because the function prologue moves it to a different place. 16975 INCOMING is `true' when the location is needed in the context of 16976 the called function, and `false' in the context of the caller. 16977 16978 If INCOMING is `true' and the address is to be found on the stack, 16979 return a `mem' which refers to the frame pointer. 16980 16981 -- Macro: PCC_STATIC_STRUCT_RETURN 16982 Define this macro if the usual system convention on the target 16983 machine for returning structures and unions is for the called 16984 function to return the address of a static variable containing the 16985 value. 16986 16987 Do not define this if the usual system convention is for the 16988 caller to pass an address to the subroutine. 16989 16990 This macro has effect in `-fpcc-struct-return' mode, but it does 16991 nothing when you use `-freg-struct-return' mode. 16992 16993 16994File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 16995 1699611.10.10 Caller-Saves Register Allocation 16997----------------------------------------- 16998 16999If you enable it, GCC can save registers around function calls. This 17000makes it possible to use call-clobbered registers to hold variables that 17001must live across calls. 17002 17003 -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS) 17004 A C expression to determine whether it is worthwhile to consider 17005 placing a pseudo-register in a call-clobbered hard register and 17006 saving and restoring it around each function call. The expression 17007 should be 1 when this is worth doing, and 0 otherwise. 17008 17009 If you don't define this macro, a default is used which is good on 17010 most machines: `4 * CALLS < REFS'. 17011 17012 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 17013 A C expression specifying which mode is required for saving NREGS 17014 of a pseudo-register in call-clobbered hard register REGNO. If 17015 REGNO is unsuitable for caller save, `VOIDmode' should be 17016 returned. For most machines this macro need not be defined since 17017 GCC will select the smallest suitable mode. 17018 17019 17020File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 17021 1702211.10.11 Function Entry and Exit 17023-------------------------------- 17024 17025This section describes the macros that output function entry 17026("prologue") and exit ("epilogue") code. 17027 17028 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 17029 HOST_WIDE_INT SIZE) 17030 If defined, a function that outputs the assembler code for entry 17031 to a function. The prologue is responsible for setting up the 17032 stack frame, initializing the frame pointer register, saving 17033 registers that must be saved, and allocating SIZE additional bytes 17034 of storage for the local variables. SIZE is an integer. FILE is 17035 a stdio stream to which the assembler code should be output. 17036 17037 The label for the beginning of the function need not be output by 17038 this macro. That has already been done when the macro is run. 17039 17040 To determine which registers to save, the macro can refer to the 17041 array `regs_ever_live': element R is nonzero if hard register R is 17042 used anywhere within the function. This implies the function 17043 prologue should save register R, provided it is not one of the 17044 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must 17045 likewise use `regs_ever_live'.) 17046 17047 On machines that have "register windows", the function entry code 17048 does not save on the stack the registers that are in the windows, 17049 even if they are supposed to be preserved by function calls; 17050 instead it takes appropriate steps to "push" the register stack, 17051 if any non-call-used registers are used in the function. 17052 17053 On machines where functions may or may not have frame-pointers, the 17054 function entry code must vary accordingly; it must set up the frame 17055 pointer if one is wanted, and not otherwise. To determine whether 17056 a frame pointer is in wanted, the macro can refer to the variable 17057 `frame_pointer_needed'. The variable's value will be 1 at run 17058 time in a function that needs a frame pointer. *Note 17059 Elimination::. 17060 17061 The function entry code is responsible for allocating any stack 17062 space required for the function. This stack space consists of the 17063 regions listed below. In most cases, these regions are allocated 17064 in the order listed, with the last listed region closest to the 17065 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is 17066 defined, and the highest address if it is not defined). You can 17067 use a different order for a machine if doing so is more convenient 17068 or required for compatibility reasons. Except in cases where 17069 required by standard or by a debugger, there is no reason why the 17070 stack layout used by GCC need agree with that used by other 17071 compilers for a machine. 17072 17073 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 17074 If defined, a function that outputs assembler code at the end of a 17075 prologue. This should be used when the function prologue is being 17076 emitted as RTL, and you have some extra assembler that needs to be 17077 emitted. *Note prologue instruction pattern::. 17078 17079 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 17080 If defined, a function that outputs assembler code at the start of 17081 an epilogue. This should be used when the function epilogue is 17082 being emitted as RTL, and you have some extra assembler that needs 17083 to be emitted. *Note epilogue instruction pattern::. 17084 17085 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 17086 HOST_WIDE_INT SIZE) 17087 If defined, a function that outputs the assembler code for exit 17088 from a function. The epilogue is responsible for restoring the 17089 saved registers and stack pointer to their values when the 17090 function was called, and returning control to the caller. This 17091 macro takes the same arguments as the macro 17092 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are 17093 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the 17094 same way. 17095 17096 On some machines, there is a single instruction that does all the 17097 work of returning from the function. On these machines, give that 17098 instruction the name `return' and do not define the macro 17099 `TARGET_ASM_FUNCTION_EPILOGUE' at all. 17100 17101 Do not define a pattern named `return' if you want the 17102 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 17103 switches to control whether return instructions or epilogues are 17104 used, define a `return' pattern with a validity condition that 17105 tests the target switches appropriately. If the `return' 17106 pattern's validity condition is false, epilogues will be used. 17107 17108 On machines where functions may or may not have frame-pointers, the 17109 function exit code must vary accordingly. Sometimes the code for 17110 these two cases is completely different. To determine whether a 17111 frame pointer is wanted, the macro can refer to the variable 17112 `frame_pointer_needed'. The variable's value will be 1 when 17113 compiling a function that needs a frame pointer. 17114 17115 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and 17116 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 17117 The C variable `current_function_is_leaf' is nonzero for such a 17118 function. *Note Leaf Functions::. 17119 17120 On some machines, some functions pop their arguments on exit while 17121 others leave that for the caller to do. For example, the 68020 17122 when given `-mrtd' pops arguments in functions that take a fixed 17123 number of arguments. 17124 17125 Your definition of the macro `RETURN_POPS_ARGS' decides which 17126 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE' 17127 needs to know what was decided. The variable that is called 17128 `current_function_pops_args' is the number of bytes of its 17129 arguments that a function should pop. *Note Scalar Return::. 17130 17131 * A region of `current_function_pretend_args_size' bytes of 17132 uninitialized space just underneath the first argument arriving on 17133 the stack. (This may not be at the very start of the allocated 17134 stack region if the calling sequence has pushed anything else 17135 since pushing the stack arguments. But usually, on such machines, 17136 nothing else has been pushed yet, because the function prologue 17137 itself does all the pushing.) This region is used on machines 17138 where an argument may be passed partly in registers and partly in 17139 memory, and, in some cases to support the features in `<stdarg.h>'. 17140 17141 * An area of memory used to save certain registers used by the 17142 function. The size of this area, which may also include space for 17143 such things as the return address and pointers to previous stack 17144 frames, is machine-specific and usually depends on which registers 17145 have been used in the function. Machines with register windows 17146 often do not require a save area. 17147 17148 * A region of at least SIZE bytes, possibly rounded up to an 17149 allocation boundary, to contain the local variables of the 17150 function. On some machines, this region and the save area may 17151 occur in the opposite order, with the save area closer to the top 17152 of the stack. 17153 17154 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of 17155 `current_function_outgoing_args_size' bytes to be used for outgoing 17156 argument lists of the function. *Note Stack Arguments::. 17157 17158 Normally, it is necessary for the macros 17159`TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' to 17160treat leaf functions specially. The C variable 17161`current_function_is_leaf' is nonzero for such a function. 17162 17163 -- Macro: EXIT_IGNORE_STACK 17164 Define this macro as a C expression that is nonzero if the return 17165 instruction or the function epilogue ignores the value of the stack 17166 pointer; in other words, if it is safe to delete an instruction to 17167 adjust the stack pointer before a return from the function. The 17168 default is 0. 17169 17170 Note that this macro's value is relevant only for functions for 17171 which frame pointers are maintained. It is never safe to delete a 17172 final stack adjustment in a function that has no frame pointer, 17173 and the compiler knows this regardless of `EXIT_IGNORE_STACK'. 17174 17175 -- Macro: EPILOGUE_USES (REGNO) 17176 Define this macro as a C expression that is nonzero for registers 17177 that are used by the epilogue or the `return' pattern. The stack 17178 and frame pointer registers are already be assumed to be used as 17179 needed. 17180 17181 -- Macro: EH_USES (REGNO) 17182 Define this macro as a C expression that is nonzero for registers 17183 that are used by the exception handling mechanism, and so should 17184 be considered live on entry to an exception edge. 17185 17186 -- Macro: DELAY_SLOTS_FOR_EPILOGUE 17187 Define this macro if the function epilogue contains delay slots to 17188 which instructions from the rest of the function can be "moved". 17189 The definition should be a C expression whose value is an integer 17190 representing the number of delay slots there. 17191 17192 -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N) 17193 A C expression that returns 1 if INSN can be placed in delay slot 17194 number N of the epilogue. 17195 17196 The argument N is an integer which identifies the delay slot now 17197 being considered (since different slots may have different rules of 17198 eligibility). It is never negative and is always less than the 17199 number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE' 17200 returns). If you reject a particular insn for a given delay slot, 17201 in principle, it may be reconsidered for a subsequent delay slot. 17202 Also, other insns may (at least in principle) be considered for 17203 the so far unfilled delay slot. 17204 17205 The insns accepted to fill the epilogue delay slots are put in an 17206 RTL list made with `insn_list' objects, stored in the variable 17207 `current_function_epilogue_delay_list'. The insn for the first 17208 delay slot comes first in the list. Your definition of the macro 17209 `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by 17210 outputting the insns in this list, usually by calling 17211 `final_scan_insn'. 17212 17213 You need not define this macro if you did not define 17214 `DELAY_SLOTS_FOR_EPILOGUE'. 17215 17216 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 17217 THUNK_FNDECL, HOST_WIDE_INT DELTA, tree FUNCTION) 17218 A function that outputs the assembler code for a thunk function, 17219 used to implement C++ virtual function calls with multiple 17220 inheritance. The thunk acts as a wrapper around a virtual 17221 function, adjusting the implicit object parameter before handing 17222 control off to the real function. 17223 17224 First, emit code to add the integer DELTA to the location that 17225 contains the incoming first argument. Assume that this argument 17226 contains a pointer, and is the one used to pass the `this' pointer 17227 in C++. This is the incoming argument _before_ the function 17228 prologue, e.g. `%o0' on a sparc. The addition must preserve the 17229 values of all other incoming arguments. 17230 17231 After the addition, emit code to jump to FUNCTION, which is a 17232 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does 17233 not touch the return address. Hence returning from FUNCTION will 17234 return to whoever called the current `thunk'. 17235 17236 The effect must be as if FUNCTION had been called directly with 17237 the adjusted first argument. This macro is responsible for 17238 emitting all of the code for a thunk function; 17239 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 17240 are not invoked. 17241 17242 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 17243 been extracted from it.) It might possibly be useful on some 17244 targets, but probably not. 17245 17246 If you do not define this macro, the target-independent code in 17247 the C++ front end will generate a less efficient heavyweight thunk 17248 that calls FUNCTION instead of jumping to it. The generic 17249 approach does not support varargs. 17250 17251 -- Target Hook: void TARGET_ASM_OUTPUT_MI_VCALL_THUNK (FILE *FILE, 17252 tree THUNK_FNDECL, HOST_WIDE_INT DELTA, int VCALL_OFFSET, 17253 tree FUNCTION) 17254 A function like `TARGET_ASM_OUTPUT_MI_THUNK', except that if 17255 VCALL_OFFSET is nonzero, an additional adjustment should be made 17256 after adding `delta'. In particular, if P is the adjusted 17257 pointer, the following adjustment should be made: 17258 17259 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 17260 17261 If this function is defined, it will always be used in place of 17262 `TARGET_ASM_OUTPUT_MI_THUNK'. 17263 17264 17265File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 17266 1726711.10.12 Generating Code for Profiling 17268-------------------------------------- 17269 17270These macros will help you generate code for profiling. 17271 17272 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 17273 A C statement or compound statement to output to FILE some 17274 assembler code to call the profiling subroutine `mcount'. 17275 17276 The details of how `mcount' expects to be called are determined by 17277 your operating system environment, not by GCC. To figure them out, 17278 compile a small program for profiling using the system's installed 17279 C compiler and look at the assembler code that results. 17280 17281 Older implementations of `mcount' expect the address of a counter 17282 variable to be loaded into some register. The name of this 17283 variable is `LP' followed by the number LABELNO, so you would 17284 generate the name using `LP%d' in a `fprintf'. 17285 17286 -- Macro: PROFILE_HOOK 17287 A C statement or compound statement to output to FILE some assembly 17288 code to call the profiling subroutine `mcount' even the target does 17289 not support profiling. 17290 17291 -- Macro: NO_PROFILE_COUNTERS 17292 Define this macro if the `mcount' subroutine on your system does 17293 not need a counter variable allocated for each function. This is 17294 true for almost all modern implementations. If you define this 17295 macro, you must not use the LABELNO argument to 17296 `FUNCTION_PROFILER'. 17297 17298 -- Macro: PROFILE_BEFORE_PROLOGUE 17299 Define this macro if the code for function profiling should come 17300 before the function prologue. Normally, the profiling code comes 17301 after. 17302 17303 17304File: gccint.info, Node: Tail Calls, Prev: Profiling, Up: Stack and Calling 17305 1730611.10.13 Permitting tail calls 17307------------------------------ 17308 17309 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 17310 EXP) 17311 True if it is ok to do sibling call optimization for the specified 17312 call expression EXP. DECL will be the called function, or `NULL' 17313 if this is an indirect call. 17314 17315 It is not uncommon for limitations of calling conventions to 17316 prevent tail calls to functions outside the current unit of 17317 translation, or during PIC compilation. The hook is used to 17318 enforce these restrictions, as the `sibcall' md pattern can not 17319 fail, or fall over to a "normal" call. The criteria for 17320 successful sibling call optimization may vary greatly between 17321 different architectures. 17322 17323 17324File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 17325 1732611.11 Implementing the Varargs Macros 17327===================================== 17328 17329GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that 17330work without change on machines that pass arguments on the stack. 17331Other machines require their own implementations of varargs, and the 17332two machine independent header files must have conditionals to include 17333it. 17334 17335 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in 17336the calling convention for `va_start'. The traditional implementation 17337takes just one argument, which is the variable in which to store the 17338argument pointer. The ISO implementation of `va_start' takes an 17339additional second argument. The user is supposed to write the last 17340named argument of the function here. 17341 17342 However, `va_start' should not use this argument. The way to find 17343the end of the named arguments is with the built-in functions described 17344below. 17345 17346 -- Macro: __builtin_saveregs () 17347 Use this built-in function to save the argument registers in 17348 memory so that the varargs mechanism can access them. Both ISO 17349 and traditional versions of `va_start' must use 17350 `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see 17351 below) instead. 17352 17353 On some machines, `__builtin_saveregs' is open-coded under the 17354 control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines, 17355 it calls a routine written in assembler language, found in 17356 `libgcc2.c'. 17357 17358 Code generated for the call to `__builtin_saveregs' appears at the 17359 beginning of the function, as opposed to where the call to 17360 `__builtin_saveregs' is written, regardless of what the code is. 17361 This is because the registers must be saved before the function 17362 starts to use them for its own purposes. 17363 17364 -- Macro: __builtin_args_info (CATEGORY) 17365 Use this built-in function to find the first anonymous arguments in 17366 registers. 17367 17368 In general, a machine may have several categories of registers 17369 used for arguments, each for a particular category of data types. 17370 (For example, on some machines, floating-point registers are used 17371 for floating-point arguments while other arguments are passed in 17372 the general registers.) To make non-varargs functions use the 17373 proper calling convention, you have defined the `CUMULATIVE_ARGS' 17374 data type to record how many registers in each category have been 17375 used so far 17376 17377 `__builtin_args_info' accesses the same data structure of type 17378 `CUMULATIVE_ARGS' after the ordinary argument layout is finished 17379 with it, with CATEGORY specifying which word to access. Thus, the 17380 value indicates the first unused register in a given category. 17381 17382 Normally, you would use `__builtin_args_info' in the implementation 17383 of `va_start', accessing each category just once and storing the 17384 value in the `va_list' object. This is because `va_list' will 17385 have to update the values, and there is no way to alter the values 17386 accessed by `__builtin_args_info'. 17387 17388 -- Macro: __builtin_next_arg (LASTARG) 17389 This is the equivalent of `__builtin_args_info', for stack 17390 arguments. It returns the address of the first anonymous stack 17391 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns 17392 the address of the location above the first anonymous stack 17393 argument. Use it in `va_start' to initialize the pointer for 17394 fetching arguments from the stack. Also use it in `va_start' to 17395 verify that the second parameter LASTARG is the last named argument 17396 of the current function. 17397 17398 -- Macro: __builtin_classify_type (OBJECT) 17399 Since each machine has its own conventions for which data types are 17400 passed in which kind of register, your implementation of `va_arg' 17401 has to embody these conventions. The easiest way to categorize the 17402 specified data type is to use `__builtin_classify_type' together 17403 with `sizeof' and `__alignof__'. 17404 17405 `__builtin_classify_type' ignores the value of OBJECT, considering 17406 only its data type. It returns an integer describing what kind of 17407 type that is--integer, floating, pointer, structure, and so on. 17408 17409 The file `typeclass.h' defines an enumeration that you can use to 17410 interpret the values of `__builtin_classify_type'. 17411 17412 These machine description macros help implement varargs: 17413 17414 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 17415 If defined, this hook produces the machine-specific code for a 17416 call to `__builtin_saveregs'. This code will be moved to the very 17417 beginning of the function, before any parameter access are made. 17418 The return value of this function should be an RTX that contains 17419 the value to use as the return of `__builtin_saveregs'. 17420 17421 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS 17422 *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int 17423 *PRETEND_ARGS_SIZE, int SECOND_TIME) 17424 This target hook offers an alternative to using 17425 `__builtin_saveregs' and defining the hook 17426 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 17427 register arguments into the stack so that all the arguments appear 17428 to have been passed consecutively on the stack. Once this is 17429 done, you can use the standard implementation of varargs that 17430 works for machines that pass all their arguments on the stack. 17431 17432 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data 17433 structure, containing the values that are obtained after 17434 processing the named arguments. The arguments MODE and TYPE 17435 describe the last named argument--its machine mode and its data 17436 type as a tree node. 17437 17438 The target hook should do two things: first, push onto the stack 17439 all the argument registers _not_ used for the named arguments, and 17440 second, store the size of the data thus pushed into the 17441 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 17442 that you store here will serve as additional offset for setting up 17443 the stack frame. 17444 17445 Because you must generate code to push the anonymous arguments at 17446 compile time without knowing their data types, 17447 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 17448 have just a single category of argument register and use it 17449 uniformly for all data types. 17450 17451 If the argument SECOND_TIME is nonzero, it means that the 17452 arguments of the function are being analyzed for the second time. 17453 This happens for an inline function, which is not actually 17454 compiled until the end of the source file. The hook 17455 `TARGET_SETUP_INCOMING_VARARGS' should not generate any 17456 instructions in this case. 17457 17458 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS 17459 *CA) 17460 Define this hook to return `true' if the location where a function 17461 argument is passed depends on whether or not it is a named 17462 argument. 17463 17464 This hook controls how the NAMED argument to `FUNCTION_ARG' is set 17465 for varargs and stdarg functions. If this hook returns `true', 17466 the NAMED argument is always true for named arguments, and false 17467 for unnamed arguments. If it returns `false', but 17468 `TARGET_PRETEND_OUTOGOING_VARARGS_NAMED' returns `true', then all 17469 arguments are treated as named. Otherwise, all named arguments 17470 except the last are treated as named. 17471 17472 You need not define this hook if it always returns zero. 17473 17474 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 17475 If you need to conditionally change ABIs so that one works with 17476 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 17477 `TARGET_SETUP_INCOMING_VARARGS' nor 17478 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook 17479 to return `true' if `SETUP_INCOMING_VARARGS' is used, `false' 17480 otherwise. Otherwise, you should not define this hook. 17481 17482 17483File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 17484 1748511.12 Trampolines for Nested Functions 17486====================================== 17487 17488A "trampoline" is a small piece of code that is created at run time 17489when the address of a nested function is taken. It normally resides on 17490the stack, in the stack frame of the containing function. These macros 17491tell GCC how to generate code to allocate and initialize a trampoline. 17492 17493 The instructions in the trampoline must do two things: load a 17494constant address into the static chain register, and jump to the real 17495address of the nested function. On CISC machines such as the m68k, 17496this requires two instructions, a move immediate and a jump. Then the 17497two addresses exist in the trampoline as word-long immediate operands. 17498On RISC machines, it is often necessary to load each address into a 17499register in two parts. Then pieces of each address form separate 17500immediate operands. 17501 17502 The code generated to initialize the trampoline must store the 17503variable parts--the static chain value and the function address--into 17504the immediate operands of the instructions. On a CISC machine, this is 17505simply a matter of copying each address to a memory reference at the 17506proper offset from the start of the trampoline. On a RISC machine, it 17507may be necessary to take out pieces of the address and store them 17508separately. 17509 17510 -- Macro: TRAMPOLINE_TEMPLATE (FILE) 17511 A C statement to output, on the stream FILE, assembler code for a 17512 block of data that contains the constant parts of a trampoline. 17513 This code should not include a label--the label is taken care of 17514 automatically. 17515 17516 If you do not define this macro, it means no template is needed 17517 for the target. Do not define this macro on systems where the 17518 block move code to copy the trampoline into place would be larger 17519 than the code to generate it on the spot. 17520 17521 -- Macro: TRAMPOLINE_SECTION 17522 The name of a subroutine to switch to the section in which the 17523 trampoline template is to be placed (*note Sections::). The 17524 default is a value of `readonly_data_section', which places the 17525 trampoline in the section containing read-only data. 17526 17527 -- Macro: TRAMPOLINE_SIZE 17528 A C expression for the size in bytes of the trampoline, as an 17529 integer. 17530 17531 -- Macro: TRAMPOLINE_ALIGNMENT 17532 Alignment required for trampolines, in bits. 17533 17534 If you don't define this macro, the value of `BIGGEST_ALIGNMENT' 17535 is used for aligning trampolines. 17536 17537 -- Macro: INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN) 17538 A C statement to initialize the variable parts of a trampoline. 17539 ADDR is an RTX for the address of the trampoline; FNADDR is an RTX 17540 for the address of the nested function; STATIC_CHAIN is an RTX for 17541 the static chain value that should be passed to the function when 17542 it is called. 17543 17544 -- Macro: TRAMPOLINE_ADJUST_ADDRESS (ADDR) 17545 A C statement that should perform any machine-specific adjustment 17546 in the address of the trampoline. Its argument contains the 17547 address that was passed to `INITIALIZE_TRAMPOLINE'. In case the 17548 address to be used for a function call should be different from 17549 the address in which the template was stored, the different 17550 address should be assigned to ADDR. If this macro is not defined, 17551 ADDR will be used for function calls. 17552 17553 If this macro is not defined, by default the trampoline is 17554 allocated as a stack slot. This default is right for most 17555 machines. The exceptions are machines where it is impossible to 17556 execute instructions in the stack area. On such machines, you may 17557 have to implement a separate stack, using this macro in 17558 conjunction with `TARGET_ASM_FUNCTION_PROLOGUE' and 17559 `TARGET_ASM_FUNCTION_EPILOGUE'. 17560 17561 FP points to a data structure, a `struct function', which 17562 describes the compilation status of the immediate containing 17563 function of the function which the trampoline is for. The stack 17564 slot for the trampoline is in the stack frame of this containing 17565 function. Other allocation strategies probably must do something 17566 analogous with this information. 17567 17568 Implementing trampolines is difficult on many machines because they 17569have separate instruction and data caches. Writing into a stack 17570location fails to clear the memory in the instruction cache, so when 17571the program jumps to that location, it executes the old contents. 17572 17573 Here are two possible solutions. One is to clear the relevant parts 17574of the instruction cache whenever a trampoline is set up. The other is 17575to make all trampolines identical, by having them jump to a standard 17576subroutine. The former technique makes trampoline execution faster; the 17577latter makes initialization faster. 17578 17579 To clear the instruction cache when a trampoline is initialized, 17580define the following macro. 17581 17582 -- Macro: CLEAR_INSN_CACHE (BEG, END) 17583 If defined, expands to a C expression clearing the _instruction 17584 cache_ in the specified interval. The definition of this macro 17585 would typically be a series of `asm' statements. Both BEG and END 17586 are both pointer expressions. 17587 17588 The operating system may also require the stack to be made executable 17589before calling the trampoline. To implement this requirement, define 17590the following macro. 17591 17592 -- Macro: ENABLE_EXECUTE_STACK 17593 Define this macro if certain operations must be performed before 17594 executing code located on the stack. The macro should expand to a 17595 series of C file-scope constructs (e.g. functions) and provide a 17596 unique entry point named `__enable_execute_stack'. The target is 17597 responsible for emitting calls to the entry point in the code, for 17598 example from the `INITIALIZE_TRAMPOLINE' macro. 17599 17600 To use a standard subroutine, define the following macro. In 17601addition, you must make sure that the instructions in a trampoline fill 17602an entire cache line with identical instructions, or else ensure that 17603the beginning of the trampoline code is always aligned at the same 17604point in its cache line. Look in `m68k.h' as a guide. 17605 17606 -- Macro: TRANSFER_FROM_TRAMPOLINE 17607 Define this macro if trampolines need a special subroutine to do 17608 their work. The macro should expand to a series of `asm' 17609 statements which will be compiled with GCC. They go in a library 17610 function named `__transfer_from_trampoline'. 17611 17612 If you need to avoid executing the ordinary prologue code of a 17613 compiled C function when you jump to the subroutine, you can do so 17614 by placing a special label of your own in the assembler code. Use 17615 one `asm' statement to generate an assembler label, and another to 17616 make the label global. Then trampolines can use that label to 17617 jump directly to your special assembler code. 17618 17619 17620File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 17621 1762211.13 Implicit Calls to Library Routines 17623======================================== 17624 17625Here is an explanation of implicit calls to library routines. 17626 17627 -- Macro: DECLARE_LIBRARY_RENAMES 17628 This macro, if defined, should expand to a piece of C code that 17629 will get expanded when compiling functions for libgcc.a. It can 17630 be used to provide alternate names for GCC's internal library 17631 functions if there are ABI-mandated names that the compiler should 17632 provide. 17633 17634 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 17635 This hook should declare additional library routines or rename 17636 existing ones, using the functions `set_optab_libfunc' and 17637 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls 17638 this macro after initializing all the normal library routines. 17639 17640 The default is to do nothing. Most ports don't need to define 17641 this hook. 17642 17643 -- Macro: TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 17644 This macro should return `true' if the library routine that 17645 implements the floating point comparison operator COMPARISON in 17646 mode MODE will return a boolean, and FALSE if it will return a 17647 tristate. 17648 17649 GCC's own floating point libraries return tristates from the 17650 comparison operators, so the default returns false always. Most 17651 ports don't need to define this macro. 17652 17653 -- Macro: US_SOFTWARE_GOFAST 17654 Define this macro if your system C library uses the US Software 17655 GOFAST library to provide floating point emulation. 17656 17657 In addition to defining this macro, your architecture must set 17658 `TARGET_INIT_LIBFUNCS' to `gofast_maybe_init_libfuncs', or else 17659 call that function from its version of that hook. It is defined 17660 in `config/gofast.h', which must be included by your 17661 architecture's `CPU.c' file. See `sparc/sparc.c' for an example. 17662 17663 If this macro is defined, the 17664 `TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL' target hook must return 17665 false for `SFmode' and `DFmode' comparisons. 17666 17667 -- Macro: TARGET_EDOM 17668 The value of `EDOM' on the target machine, as a C integer constant 17669 expression. If you don't define this macro, GCC does not attempt 17670 to deposit the value of `EDOM' into `errno' directly. Look in 17671 `/usr/include/errno.h' to find the value of `EDOM' on your system. 17672 17673 If you do not define `TARGET_EDOM', then compiled code reports 17674 domain errors by calling the library function and letting it 17675 report the error. If mathematical functions on your system use 17676 `matherr' when there is an error, then you should leave 17677 `TARGET_EDOM' undefined so that `matherr' is used normally. 17678 17679 -- Macro: GEN_ERRNO_RTX 17680 Define this macro as a C expression to create an rtl expression 17681 that refers to the global "variable" `errno'. (On certain systems, 17682 `errno' may not actually be a variable.) If you don't define this 17683 macro, a reasonable default is used. 17684 17685 -- Macro: TARGET_MEM_FUNCTIONS 17686 Define this macro if GCC should generate calls to the ISO C (and 17687 System V) library functions `memcpy', `memmove' and `memset' 17688 rather than the BSD functions `bcopy' and `bzero'. 17689 17690 -- Macro: TARGET_C99_FUNCTIONS 17691 When this macro is nonzero, GCC will implicitly optimize `sin' 17692 calls into `sinf' and similarly for other functions defined by C99 17693 standard. The default is nonzero that should be proper value for 17694 most modern systems, however number of existing systems lacks 17695 support for these functions in the runtime so they needs this 17696 macro to be redefined to 0. 17697 17698 -- Macro: NEXT_OBJC_RUNTIME 17699 Define this macro to generate code for Objective-C message sending 17700 using the calling convention of the NeXT system. This calling 17701 convention involves passing the object, the selector and the 17702 method arguments all at once to the method-lookup library function. 17703 17704 The default calling convention passes just the object and the 17705 selector to the lookup function, which returns a pointer to the 17706 method. 17707 17708 17709File: gccint.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros 17710 1771111.14 Addressing Modes 17712====================== 17713 17714This is about addressing modes. 17715 17716 -- Macro: HAVE_PRE_INCREMENT 17717 -- Macro: HAVE_PRE_DECREMENT 17718 -- Macro: HAVE_POST_INCREMENT 17719 -- Macro: HAVE_POST_DECREMENT 17720 A C expression that is nonzero if the machine supports 17721 pre-increment, pre-decrement, post-increment, or post-decrement 17722 addressing respectively. 17723 17724 -- Macro: HAVE_PRE_MODIFY_DISP 17725 -- Macro: HAVE_POST_MODIFY_DISP 17726 A C expression that is nonzero if the machine supports pre- or 17727 post-address side-effect generation involving constants other than 17728 the size of the memory operand. 17729 17730 -- Macro: HAVE_PRE_MODIFY_REG 17731 -- Macro: HAVE_POST_MODIFY_REG 17732 A C expression that is nonzero if the machine supports pre- or 17733 post-address side-effect generation involving a register 17734 displacement. 17735 17736 -- Macro: CONSTANT_ADDRESS_P (X) 17737 A C expression that is 1 if the RTX X is a constant which is a 17738 valid address. On most machines, this can be defined as 17739 `CONSTANT_P (X)', but a few machines are more restrictive in which 17740 constant addresses are supported. 17741 17742 -- Macro: CONSTANT_P (X) 17743 `CONSTANT_P', which is defined by target-independent code, accepts 17744 integer-values expressions whose values are not explicitly known, 17745 such as `symbol_ref', `label_ref', and `high' expressions and 17746 `const' arithmetic expressions, in addition to `const_int' and 17747 `const_double' expressions. 17748 17749 -- Macro: MAX_REGS_PER_ADDRESS 17750 A number, the maximum number of registers that can appear in a 17751 valid memory address. Note that it is up to you to specify a 17752 value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' 17753 would ever accept. 17754 17755 -- Macro: GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 17756 A C compound statement with a conditional `goto LABEL;' executed 17757 if X (an RTX) is a legitimate memory address on the target machine 17758 for a memory operand of mode MODE. 17759 17760 It usually pays to define several simpler macros to serve as 17761 subroutines for this one. Otherwise it may be too complicated to 17762 understand. 17763 17764 This macro must exist in two variants: a strict variant and a 17765 non-strict one. The strict variant is used in the reload pass. It 17766 must be defined so that any pseudo-register that has not been 17767 allocated a hard register is considered a memory reference. In 17768 contexts where some kind of register is required, a pseudo-register 17769 with no hard register must be rejected. 17770 17771 The non-strict variant is used in other passes. It must be 17772 defined to accept all pseudo-registers in every context where some 17773 kind of register is required. 17774 17775 Compiler source files that want to use the strict variant of this 17776 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef 17777 REG_OK_STRICT' conditional to define the strict variant in that 17778 case and the non-strict variant otherwise. 17779 17780 Subroutines to check for acceptable registers for various purposes 17781 (one for base registers, one for index registers, and so on) are 17782 typically among the subroutines used to define 17783 `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros 17784 need have two variants; the higher levels of macros may be the 17785 same whether strict or not. 17786 17787 Normally, constant addresses which are the sum of a `symbol_ref' 17788 and an integer are stored inside a `const' RTX to mark them as 17789 constant. Therefore, there is no need to recognize such sums 17790 specifically as legitimate addresses. Normally you would simply 17791 recognize any `const' as legitimate. 17792 17793 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 17794 sums that are not marked with `const'. It assumes that a naked 17795 `plus' indicates indexing. If so, then you _must_ reject such 17796 naked constant sums as illegitimate addresses, so that none of 17797 them will be given to `PRINT_OPERAND_ADDRESS'. 17798 17799 On some machines, whether a symbolic address is legitimate depends 17800 on the section that the address refers to. On these machines, 17801 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the 17802 information into the `symbol_ref', and then check for it here. 17803 When you see a `const', you will have to look inside it to find the 17804 `symbol_ref' in order to determine the section. *Note Assembler 17805 Format::. 17806 17807 -- Macro: REG_OK_FOR_BASE_P (X) 17808 A C expression that is nonzero if X (assumed to be a `reg' RTX) is 17809 valid for use as a base register. For hard registers, it should 17810 always accept those which the hardware permits and reject the 17811 others. Whether the macro accepts or rejects pseudo registers 17812 must be controlled by `REG_OK_STRICT' as described above. This 17813 usually requires two variant definitions, of which `REG_OK_STRICT' 17814 controls the one actually used. 17815 17816 -- Macro: REG_MODE_OK_FOR_BASE_P (X, MODE) 17817 A C expression that is just like `REG_OK_FOR_BASE_P', except that 17818 that expression may examine the mode of the memory reference in 17819 MODE. You should define this macro if the mode of the memory 17820 reference affects whether a register may be used as a base 17821 register. If you define this macro, the compiler will use it 17822 instead of `REG_OK_FOR_BASE_P'. 17823 17824 -- Macro: REG_OK_FOR_INDEX_P (X) 17825 A C expression that is nonzero if X (assumed to be a `reg' RTX) is 17826 valid for use as an index register. 17827 17828 The difference between an index register and a base register is 17829 that the index register may be scaled. If an address involves the 17830 sum of two registers, neither one of them scaled, then either one 17831 may be labeled the "base" and the other the "index"; but whichever 17832 labeling is used must fit the machine's constraints of which 17833 registers may serve in each capacity. The compiler will try both 17834 labelings, looking for one that is valid, and will reload one or 17835 both registers only if neither labeling works. 17836 17837 -- Macro: FIND_BASE_TERM (X) 17838 A C expression to determine the base term of address X. This 17839 macro is used in only one place: `find_base_term' in alias.c. 17840 17841 It is always safe for this macro to not be defined. It exists so 17842 that alias analysis can understand machine-dependent addresses. 17843 17844 The typical use of this macro is to handle addresses containing a 17845 label_ref or symbol_ref within an UNSPEC. 17846 17847 -- Macro: LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN) 17848 A C compound statement that attempts to replace X with a valid 17849 memory address for an operand of mode MODE. WIN will be a C 17850 statement label elsewhere in the code; the macro definition may use 17851 17852 GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); 17853 17854 to avoid further processing if the address has become legitimate. 17855 17856 X will always be the result of a call to `break_out_memory_refs', 17857 and OLDX will be the operand that was given to that function to 17858 produce X. 17859 17860 The code generated by this macro should not alter the substructure 17861 of X. If it transforms X into a more legitimate form, it should 17862 assign X (which will always be a C variable) a new value. 17863 17864 It is not necessary for this macro to come up with a legitimate 17865 address. The compiler has standard ways of doing so in all cases. 17866 In fact, it is safe for this macro to do nothing. But often a 17867 machine-dependent strategy can generate better code. 17868 17869 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 17870 WIN) 17871 A C compound statement that attempts to replace X, which is an 17872 address that needs reloading, with a valid memory address for an 17873 operand of mode MODE. WIN will be a C statement label elsewhere 17874 in the code. It is not necessary to define this macro, but it 17875 might be useful for performance reasons. 17876 17877 For example, on the i386, it is sometimes possible to use a single 17878 reload register instead of two by reloading a sum of two pseudo 17879 registers into a register. On the other hand, for number of RISC 17880 processors offsets are limited so that often an intermediate 17881 address needs to be generated in order to address a stack slot. 17882 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 17883 intermediate addresses generated for adjacent some stack slots can 17884 be made identical, and thus be shared. 17885 17886 _Note_: This macro should be used with caution. It is necessary 17887 to know something of how reload works in order to effectively use 17888 this, and it is quite easy to produce macros that build in too 17889 much knowledge of reload internals. 17890 17891 _Note_: This macro must be able to reload an address created by a 17892 previous invocation of this macro. If it fails to handle such 17893 addresses then the compiler may generate incorrect code or abort. 17894 17895 The macro definition should use `push_reload' to indicate parts 17896 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 17897 suitable to be passed unaltered to `push_reload'. 17898 17899 The code generated by this macro must not alter the substructure of 17900 X. If it transforms X into a more legitimate form, it should 17901 assign X (which will always be a C variable) a new value. This 17902 also applies to parts that you change indirectly by calling 17903 `push_reload'. 17904 17905 The macro definition may use `strict_memory_address_p' to test if 17906 the address has become legitimate. 17907 17908 If you want to change only a part of X, one standard way of doing 17909 this is to use `copy_rtx'. Note, however, that is unshares only a 17910 single level of rtl. Thus, if the part to be changed is not at the 17911 top level, you'll need to replace first the top level. It is not 17912 necessary for this macro to come up with a legitimate address; 17913 but often a machine-dependent strategy can generate better code. 17914 17915 -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL) 17916 A C statement or compound statement with a conditional `goto 17917 LABEL;' executed if memory address X (an RTX) can have different 17918 meanings depending on the machine mode of the memory reference it 17919 is used for or if the address is valid for some modes but not 17920 others. 17921 17922 Autoincrement and autodecrement addresses typically have 17923 mode-dependent effects because the amount of the increment or 17924 decrement is the size of the operand being addressed. Some 17925 machines have other mode-dependent addresses. Many RISC machines 17926 have no mode-dependent addresses. 17927 17928 You may assume that ADDR is a valid address for the machine. 17929 17930 -- Macro: LEGITIMATE_CONSTANT_P (X) 17931 A C expression that is nonzero if X is a legitimate constant for 17932 an immediate operand on the target machine. You can assume that X 17933 satisfies `CONSTANT_P', so you need not check this. In fact, `1' 17934 is a suitable definition for this macro on machines where anything 17935 `CONSTANT_P' is valid. 17936 17937 17938File: gccint.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros 17939 1794011.15 Condition Code Status 17941=========================== 17942 17943This describes the condition code status. 17944 17945 The file `conditions.h' defines a variable `cc_status' to describe 17946how the condition code was computed (in case the interpretation of the 17947condition code depends on the instruction that it was set by). This 17948variable contains the RTL expressions on which the condition code is 17949currently based, and several standard flags. 17950 17951 Sometimes additional machine-specific flags must be defined in the 17952machine description header file. It can also add additional 17953machine-specific information by defining `CC_STATUS_MDEP'. 17954 17955 -- Macro: CC_STATUS_MDEP 17956 C code for a data type which is used for declaring the `mdep' 17957 component of `cc_status'. It defaults to `int'. 17958 17959 This macro is not used on machines that do not use `cc0'. 17960 17961 -- Macro: CC_STATUS_MDEP_INIT 17962 A C expression to initialize the `mdep' field to "empty". The 17963 default definition does nothing, since most machines don't use the 17964 field anyway. If you want to use the field, you should probably 17965 define this macro to initialize it. 17966 17967 This macro is not used on machines that do not use `cc0'. 17968 17969 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 17970 A C compound statement to set the components of `cc_status' 17971 appropriately for an insn INSN whose body is EXP. It is this 17972 macro's responsibility to recognize insns that set the condition 17973 code as a byproduct of other activity as well as those that 17974 explicitly set `(cc0)'. 17975 17976 This macro is not used on machines that do not use `cc0'. 17977 17978 If there are insns that do not set the condition code but do alter 17979 other machine registers, this macro must check to see whether they 17980 invalidate the expressions that the condition code is recorded as 17981 reflecting. For example, on the 68000, insns that store in address 17982 registers do not set the condition code, which means that usually 17983 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 17984 But suppose that the previous insn set the condition code based 17985 on location `a4@(102)' and the current insn stores a new value in 17986 `a4'. Although the condition code is not changed by this, it will 17987 no longer be true that it reflects the contents of `a4@(102)'. 17988 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 17989 to say that nothing is known about the condition code value. 17990 17991 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 17992 the results of peephole optimization: insns whose patterns are 17993 `parallel' RTXs containing various `reg', `mem' or constants which 17994 are just the operands. The RTL structure of these insns is not 17995 sufficient to indicate what the insns actually do. What 17996 `NOTICE_UPDATE_CC' should do when it sees one is just to run 17997 `CC_STATUS_INIT'. 17998 17999 A possible definition of `NOTICE_UPDATE_CC' is to call a function 18000 that looks at an attribute (*note Insn Attributes::) named, for 18001 example, `cc'. This avoids having detailed information about 18002 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 18003 18004 -- Macro: SELECT_CC_MODE (OP, X, Y) 18005 Returns a mode from class `MODE_CC' to be used when comparison 18006 operation code OP is applied to rtx X and Y. For example, on the 18007 SPARC, `SELECT_CC_MODE' is defined as (see *note Jump Patterns:: 18008 for a description of the reason for this definition) 18009 18010 #define SELECT_CC_MODE(OP,X,Y) \ 18011 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 18012 ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ 18013 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 18014 || GET_CODE (X) == NEG) \ 18015 ? CC_NOOVmode : CCmode)) 18016 18017 You should define this macro if and only if you define extra CC 18018 modes in `MACHINE-modes.def'. 18019 18020 -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1) 18021 On some machines not all possible comparisons are defined, but you 18022 can convert an invalid comparison into a valid one. For example, 18023 the Alpha does not have a `GT' comparison, but you can use an `LT' 18024 comparison instead and swap the order of the operands. 18025 18026 On such machines, define this macro to be a C statement to do any 18027 required conversions. CODE is the initial comparison code and OP0 18028 and OP1 are the left and right operands of the comparison, 18029 respectively. You should modify CODE, OP0, and OP1 as required. 18030 18031 GCC will not assume that the comparison resulting from this macro 18032 is valid but will see if the resulting insn matches a pattern in 18033 the `md' file. 18034 18035 You need not define this macro if it would never change the 18036 comparison code or operands. 18037 18038 -- Macro: REVERSIBLE_CC_MODE (MODE) 18039 A C expression whose value is one if it is always safe to reverse a 18040 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 18041 return MODE for a floating-point inequality comparison, then 18042 `REVERSIBLE_CC_MODE (MODE)' must be zero. 18043 18044 You need not define this macro if it would always returns zero or 18045 if the floating-point format is anything other than 18046 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 18047 the SPARC, where floating-point inequality comparisons are always 18048 given `CCFPEmode': 18049 18050 #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) 18051 18052 -- Macro: REVERSE_CONDITION (CODE, MODE) 18053 A C expression whose value is reversed condition code of the CODE 18054 for comparison done in CC_MODE MODE. The macro is used only in 18055 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 18056 case machine has some non-standard way how to reverse certain 18057 conditionals. For instance in case all floating point conditions 18058 are non-trapping, compiler may freely convert unordered compares 18059 to ordered one. Then definition may look like: 18060 18061 #define REVERSE_CONDITION(CODE, MODE) \ 18062 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 18063 : reverse_condition_maybe_unordered (CODE)) 18064 18065 -- Macro: REVERSE_CONDEXEC_PREDICATES_P (CODE1, CODE2) 18066 A C expression that returns true if the conditional execution 18067 predicate CODE1 is the inverse of CODE2 and vice versa. Define 18068 this to return 0 if the target has conditional execution 18069 predicates that cannot be reversed safely. If no expansion is 18070 specified, this macro is defined as follows: 18071 18072 #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \ 18073 ((x) == reverse_condition (y)) 18074 18075 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *, 18076 unsigned int *) 18077 On targets which do not use `(cc0)', and which use a hard register 18078 rather than a pseudo-register to hold condition codes, the regular 18079 CSE passes are often not able to identify cases in which the hard 18080 register is set to a common value. Use this hook to enable a 18081 small pass which optimizes such cases. This hook should return 18082 true to enable this pass, and it should set the integers to which 18083 its arguments point to the hard register numbers used for 18084 condition codes. When there is only one such register, as is true 18085 on most systems, the integer pointed to by the second argument 18086 should be set to `INVALID_REGNUM'. 18087 18088 The default version of this hook returns false. 18089 18090 -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum 18091 machine_mode, enum machine_mode) 18092 On targets which use multiple condition code modes in class 18093 `MODE_CC', it is sometimes the case that a comparison can be 18094 validly done in more than one mode. On such a system, define this 18095 target hook to take two mode arguments and to return a mode in 18096 which both comparisons may be validly done. If there is no such 18097 mode, return `VOIDmode'. 18098 18099 The default version of this hook checks whether the modes are the 18100 same. If they are, it returns that mode. If they are different, 18101 it returns `VOIDmode'. 18102 18103 18104File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 18105 1810611.16 Describing Relative Costs of Operations 18107============================================= 18108 18109These macros let you describe the relative speed of various operations 18110on the target machine. 18111 18112 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 18113 A C expression for the cost of moving data of mode MODE from a 18114 register in class FROM to one in class TO. The classes are 18115 expressed using the enumeration values such as `GENERAL_REGS'. A 18116 value of 2 is the default; other values are interpreted relative to 18117 that. 18118 18119 It is not required that the cost always equal 2 when FROM is the 18120 same as TO; on some machines it is expensive to move between 18121 registers if they are not general registers. 18122 18123 If reload sees an insn consisting of a single `set' between two 18124 hard registers, and if `REGISTER_MOVE_COST' applied to their 18125 classes returns a value of 2, reload does not check to ensure that 18126 the constraints of the insn are met. Setting a cost of other than 18127 2 will allow reload to verify that the constraints are met. You 18128 should do this if the `movM' pattern's constraints do not allow 18129 such copying. 18130 18131 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 18132 A C expression for the cost of moving data of mode MODE between a 18133 register of class CLASS and memory; IN is zero if the value is to 18134 be written to memory, nonzero if it is to be read in. This cost 18135 is relative to those in `REGISTER_MOVE_COST'. If moving between 18136 registers and memory is more expensive than between two registers, 18137 you should define this macro to express the relative cost. 18138 18139 If you do not define this macro, GCC uses a default cost of 4 plus 18140 the cost of copying via a secondary reload register, if one is 18141 needed. If your machine requires a secondary reload register to 18142 copy between memory and a register of CLASS but the reload 18143 mechanism is more complex than copying via an intermediate, define 18144 this macro to reflect the actual cost of the move. 18145 18146 GCC defines the function `memory_move_secondary_cost' if secondary 18147 reloads are needed. It computes the costs due to copying via a 18148 secondary register. If your machine copies from memory using a 18149 secondary register in the conventional way but the default base 18150 value of 4 is not correct for your machine, define this macro to 18151 add some other value to the result of that function. The 18152 arguments to that function are the same as to this macro. 18153 18154 -- Macro: BRANCH_COST 18155 A C expression for the cost of a branch instruction. A value of 1 18156 is the default; other values are interpreted relative to that. 18157 18158 Here are additional macros which do not specify precise relative 18159costs, but only that certain actions are more expensive than GCC would 18160ordinarily expect. 18161 18162 -- Macro: SLOW_BYTE_ACCESS 18163 Define this macro as a C expression which is nonzero if accessing 18164 less than a word of memory (i.e. a `char' or a `short') is no 18165 faster than accessing a word of memory, i.e., if such access 18166 require more than one instruction or if there is no difference in 18167 cost between byte and (aligned) word loads. 18168 18169 When this macro is not defined, the compiler will access a field by 18170 finding the smallest containing object; when it is defined, a 18171 fullword load will be used if alignment permits. Unless bytes 18172 accesses are faster than word accesses, using word accesses is 18173 preferable since it may eliminate subsequent memory access if 18174 subsequent accesses occur to other fields in the same word of the 18175 structure, but to different bytes. 18176 18177 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 18178 Define this macro to be the value 1 if memory accesses described 18179 by the MODE and ALIGNMENT parameters have a cost many times greater 18180 than aligned accesses, for example if they are emulated in a trap 18181 handler. 18182 18183 When this macro is nonzero, the compiler will act as if 18184 `STRICT_ALIGNMENT' were nonzero when generating code for block 18185 moves. This can cause significantly more instructions to be 18186 produced. Therefore, do not set this macro nonzero if unaligned 18187 accesses only add a cycle or two to the time for a memory access. 18188 18189 If the value of this macro is always zero, it need not be defined. 18190 If this macro is defined, it should produce a nonzero value when 18191 `STRICT_ALIGNMENT' is nonzero. 18192 18193 -- Macro: MOVE_RATIO 18194 The threshold of number of scalar memory-to-memory move insns, 18195 _below_ which a sequence of insns should be generated instead of a 18196 string move insn or a library call. Increasing the value will 18197 always make code faster, but eventually incurs high cost in 18198 increased code size. 18199 18200 Note that on machines where the corresponding move insn is a 18201 `define_expand' that emits a sequence of insns, this macro counts 18202 the number of such sequences. 18203 18204 If you don't define this, a reasonable default is used. 18205 18206 -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT) 18207 A C expression used to determine whether `move_by_pieces' will be 18208 used to copy a chunk of memory, or whether some other block move 18209 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 18210 returns less than `MOVE_RATIO'. 18211 18212 -- Macro: MOVE_MAX_PIECES 18213 A C expression used by `move_by_pieces' to determine the largest 18214 unit a load or store used to copy memory is. Defaults to 18215 `MOVE_MAX'. 18216 18217 -- Macro: CLEAR_RATIO 18218 The threshold of number of scalar move insns, _below_ which a 18219 sequence of insns should be generated to clear memory instead of a 18220 string clear insn or a library call. Increasing the value will 18221 always make code faster, but eventually incurs high cost in 18222 increased code size. 18223 18224 If you don't define this, a reasonable default is used. 18225 18226 -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT) 18227 A C expression used to determine whether `clear_by_pieces' will be 18228 used to clear a chunk of memory, or whether some other block clear 18229 mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns' 18230 returns less than `CLEAR_RATIO'. 18231 18232 -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT) 18233 A C expression used to determine whether `store_by_pieces' will be 18234 used to set a chunk of memory to a constant value, or whether some 18235 other mechanism will be used. Used by `__builtin_memset' when 18236 storing values other than constant zero and by `__builtin_strcpy' 18237 when when called with a constant source string. Defaults to 18238 `MOVE_BY_PIECES_P'. 18239 18240 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 18241 A C expression used to determine whether a load postincrement is a 18242 good thing to use for a given mode. Defaults to the value of 18243 `HAVE_POST_INCREMENT'. 18244 18245 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 18246 A C expression used to determine whether a load postdecrement is a 18247 good thing to use for a given mode. Defaults to the value of 18248 `HAVE_POST_DECREMENT'. 18249 18250 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 18251 A C expression used to determine whether a load preincrement is a 18252 good thing to use for a given mode. Defaults to the value of 18253 `HAVE_PRE_INCREMENT'. 18254 18255 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 18256 A C expression used to determine whether a load predecrement is a 18257 good thing to use for a given mode. Defaults to the value of 18258 `HAVE_PRE_DECREMENT'. 18259 18260 -- Macro: USE_STORE_POST_INCREMENT (MODE) 18261 A C expression used to determine whether a store postincrement is 18262 a good thing to use for a given mode. Defaults to the value of 18263 `HAVE_POST_INCREMENT'. 18264 18265 -- Macro: USE_STORE_POST_DECREMENT (MODE) 18266 A C expression used to determine whether a store postdecrement is 18267 a good thing to use for a given mode. Defaults to the value of 18268 `HAVE_POST_DECREMENT'. 18269 18270 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 18271 This macro is used to determine whether a store preincrement is a 18272 good thing to use for a given mode. Defaults to the value of 18273 `HAVE_PRE_INCREMENT'. 18274 18275 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 18276 This macro is used to determine whether a store predecrement is a 18277 good thing to use for a given mode. Defaults to the value of 18278 `HAVE_PRE_DECREMENT'. 18279 18280 -- Macro: NO_FUNCTION_CSE 18281 Define this macro if it is as good or better to call a constant 18282 function address than to call an address kept in a register. 18283 18284 -- Macro: NO_RECURSIVE_FUNCTION_CSE 18285 Define this macro if it is as good or better for a function to call 18286 itself with an explicit address than to call an address kept in a 18287 register. 18288 18289 -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT 18290 Define this macro if a non-short-circuit operation produced by 18291 `fold_range_test ()' is optimal. This macro defaults to true if 18292 `BRANCH_COST' is greater than or equal to the value 2. 18293 18294 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int 18295 OUTER_CODE, int *TOTAL) 18296 This target hook describes the relative costs of RTL expressions. 18297 18298 The cost may depend on the precise form of the expression, which is 18299 available for examination in X, and the rtx code of the expression 18300 in which it is contained, found in OUTER_CODE. CODE is the 18301 expression code--redundant, since it can be obtained with 18302 `GET_CODE (X)'. 18303 18304 In implementing this hook, you can use the construct 18305 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions. 18306 18307 On entry to the hook, `*TOTAL' contains a default estimate for the 18308 cost of the expression. The hook should modify this value as 18309 necessary. 18310 18311 The hook returns true when all subexpressions of X have been 18312 processed, and false when `rtx_cost' should recurse. 18313 18314 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS) 18315 This hook computes the cost of an addressing mode that contains 18316 ADDRESS. If not defined, the cost is computed from the ADDRESS 18317 expression and the `TARGET_RTX_COST' hook. 18318 18319 For most CISC machines, the default cost is a good approximation 18320 of the true cost of the addressing mode. However, on RISC 18321 machines, all instructions normally have the same length and 18322 execution time. Hence all addresses will have equal costs. 18323 18324 In cases where more than one form of an address is known, the form 18325 with the lowest cost will be used. If multiple forms have the 18326 same, lowest, cost, the one that is the most complex will be used. 18327 18328 For example, suppose an address that is equal to the sum of a 18329 register and a constant is used twice in the same basic block. 18330 When this macro is not defined, the address will be computed in a 18331 register and memory references will be indirect through that 18332 register. On machines where the cost of the addressing mode 18333 containing the sum is no higher than that of a simple indirect 18334 reference, this will produce an additional instruction and 18335 possibly require an additional register. Proper specification of 18336 this macro eliminates this overhead for such machines. 18337 18338 This hook is never called with an invalid address. 18339 18340 On machines where an address involving more than one register is as 18341 cheap as an address computation involving only one register, 18342 defining `TARGET_ADDRESS_COST' to reflect this can cause two 18343 registers to be live over a region of code where only one would 18344 have been if `TARGET_ADDRESS_COST' were not defined in that 18345 manner. This effect should be considered in the definition of 18346 this macro. Equivalent costs should probably only be given to 18347 addresses with different numbers of registers on machines with 18348 lots of registers. 18349 18350 18351File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 18352 1835311.17 Adjusting the Instruction Scheduler 18354========================================= 18355 18356The instruction scheduler may need a fair amount of machine-specific 18357adjustment in order to produce good code. GCC provides several target 18358hooks for this purpose. It is usually enough to define just a few of 18359them: try the first ones in this list first. 18360 18361 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 18362 This hook returns the maximum number of instructions that can ever 18363 issue at the same time on the target machine. The default is one. 18364 Although the insn scheduler can define itself the possibility of 18365 issue an insn on the same cycle, the value can serve as an 18366 additional constraint to issue insns on the same simulated 18367 processor cycle (see hooks `TARGET_SCHED_REORDER' and 18368 `TARGET_SCHED_REORDER2'). This value must be constant over the 18369 entire compilation. If you need it to vary depending on what the 18370 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'. 18371 18372 For the automaton based pipeline interface, you could define this 18373 hook to return the value of the macro `MAX_DFA_ISSUE_RATE'. 18374 18375 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 18376 VERBOSE, rtx INSN, int MORE) 18377 This hook is executed by the scheduler after it has scheduled an 18378 insn from the ready list. It should return the number of insns 18379 which can still be issued in the current cycle. The default is 18380 `MORE - 1' for insns other than `CLOBBER' and `USE', which 18381 normally are not counted against the issue rate. You should 18382 define this hook if some insns take more machine resources than 18383 others, so that fewer insns can follow them in the same cycle. 18384 FILE is either a null pointer, or a stdio stream to write any 18385 debug output to. VERBOSE is the verbose level provided by 18386 `-fsched-verbose-N'. INSN is the instruction that was scheduled. 18387 18388 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx 18389 DEP_INSN, int COST) 18390 This function corrects the value of COST based on the relationship 18391 between INSN and DEP_INSN through the dependence LINK. It should 18392 return the new value. The default is to make no adjustment to 18393 COST. This can be used for example to specify to the scheduler 18394 using the traditional pipeline description that an output- or 18395 anti-dependence does not incur the same cost as a data-dependence. 18396 If the scheduler using the automaton based pipeline description, 18397 the cost of anti-dependence is zero and the cost of 18398 output-dependence is maximum of one and the difference of latency 18399 times of the first and the second insns. If these values are not 18400 acceptable, you could use the hook to modify them too. See also 18401 *note Automaton pipeline description::. 18402 18403 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int 18404 PRIORITY) 18405 This hook adjusts the integer scheduling priority PRIORITY of 18406 INSN. It should return the new priority. Reduce the priority to 18407 execute INSN earlier, increase the priority to execute INSN later. 18408 Do not define this hook if you do not need to adjust the 18409 scheduling priorities of insns. 18410 18411 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx 18412 *READY, int *N_READYP, int CLOCK) 18413 This hook is executed by the scheduler after it has scheduled the 18414 ready list, to allow the machine description to reorder it (for 18415 example to combine two small instructions together on `VLIW' 18416 machines). FILE is either a null pointer, or a stdio stream to 18417 write any debug output to. VERBOSE is the verbose level provided 18418 by `-fsched-verbose-N'. READY is a pointer to the ready list of 18419 instructions that are ready to be scheduled. N_READYP is a 18420 pointer to the number of elements in the ready list. The scheduler 18421 reads the ready list in reverse order, starting with 18422 READY[*N_READYP-1] and going to READY[0]. CLOCK is the timer tick 18423 of the scheduler. You may modify the ready list and the number of 18424 ready insns. The return value is the number of insns that can 18425 issue this cycle; normally this is just `issue_rate'. See also 18426 `TARGET_SCHED_REORDER2'. 18427 18428 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 18429 rtx *READY, int *N_READY, CLOCK) 18430 Like `TARGET_SCHED_REORDER', but called at a different time. That 18431 function is called whenever the scheduler starts a new cycle. 18432 This one is called once per iteration over a cycle, immediately 18433 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list 18434 and return the number of insns to be scheduled in the same cycle. 18435 Defining this hook can be useful if there are frequent situations 18436 where scheduling one insn causes other insns to become ready in 18437 the same cycle. These other insns can then be taken into account 18438 properly. 18439 18440 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx 18441 HEAD, rtx TAIL) 18442 This hook is called after evaluation forward dependencies of insns 18443 in chain given by two parameter values (HEAD and TAIL 18444 correspondingly) but before insns scheduling of the insn chain. 18445 For example, it can be used for better insn classification if it 18446 requires analysis of dependencies. This hook can use backward and 18447 forward dependencies of the insn scheduler because they are already 18448 calculated. 18449 18450 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 18451 MAX_READY) 18452 This hook is executed by the scheduler at the beginning of each 18453 block of instructions that are to be scheduled. FILE is either a 18454 null pointer, or a stdio stream to write any debug output to. 18455 VERBOSE is the verbose level provided by `-fsched-verbose-N'. 18456 MAX_READY is the maximum number of insns in the current scheduling 18457 region that can be live at the same time. This can be used to 18458 allocate scratch space if it is needed, e.g. by 18459 `TARGET_SCHED_REORDER'. 18460 18461 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 18462 This hook is executed by the scheduler at the end of each block of 18463 instructions that are to be scheduled. It can be used to perform 18464 cleanup of any actions done by the other scheduling hooks. FILE 18465 is either a null pointer, or a stdio stream to write any debug 18466 output to. VERBOSE is the verbose level provided by 18467 `-fsched-verbose-N'. 18468 18469 -- Target Hook: int TARGET_SCHED_USE_DFA_PIPELINE_INTERFACE (void) 18470 This hook is called many times during insn scheduling. If the hook 18471 returns nonzero, the automaton based pipeline description is used 18472 for insn scheduling. Otherwise the traditional pipeline 18473 description is used. The default is usage of the traditional 18474 pipeline description. 18475 18476 You should also remember that to simplify the insn scheduler 18477 sources an empty traditional pipeline description interface is 18478 generated even if there is no a traditional pipeline description 18479 in the `.md' file. The same is true for the automaton based 18480 pipeline description. That means that you should be accurate in 18481 defining the hook. 18482 18483 -- Target Hook: int TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 18484 The hook returns an RTL insn. The automaton state used in the 18485 pipeline hazard recognizer is changed as if the insn were scheduled 18486 when the new simulated processor cycle starts. Usage of the hook 18487 may simplify the automaton pipeline description for some VLIW 18488 processors. If the hook is defined, it is used only for the 18489 automaton based pipeline description. The default is not to 18490 change the state when the new simulated processor cycle starts. 18491 18492 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 18493 The hook can be used to initialize data used by the previous hook. 18494 18495 -- Target Hook: int TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 18496 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 18497 to changed the state as if the insn were scheduled when the new 18498 simulated processor cycle finishes. 18499 18500 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 18501 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 18502 used to initialize data used by the previous hook. 18503 18504 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 18505 (void) 18506 This hook controls better choosing an insn from the ready insn 18507 queue for the DFA-based insn scheduler. Usually the scheduler 18508 chooses the first insn from the queue. If the hook returns a 18509 positive value, an additional scheduler code tries all 18510 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 18511 ()' subsequent ready insns to choose an insn whose issue will 18512 result in maximal number of issued insns on the same cycle. For 18513 the VLIW processor, the code could actually solve the problem of 18514 packing simple insns into the VLIW insn. Of course, if the rules 18515 of VLIW packing are described in the automaton. 18516 18517 This code also could be used for superscalar RISC processors. Let 18518 us consider a superscalar RISC processor with 3 pipelines. Some 18519 insns can be executed in pipelines A or B, some insns can be 18520 executed only in pipelines B or C, and one insn can be executed in 18521 pipeline B. The processor may issue the 1st insn into A and the 18522 2nd one into B. In this case, the 3rd insn will wait for freeing B 18523 until the next cycle. If the scheduler issues the 3rd insn the 18524 first, the processor could issue all 3 insns per cycle. 18525 18526 Actually this code demonstrates advantages of the automaton based 18527 pipeline hazard recognizer. We try quickly and easy many insn 18528 schedules to choose the best one. 18529 18530 The default is no multipass scheduling. 18531 18532 -- Target Hook: int 18533TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx) 18534 This hook controls what insns from the ready insn queue will be 18535 considered for the multipass insn scheduling. If the hook returns 18536 zero for insn passed as the parameter, the insn will be not chosen 18537 to be issued. 18538 18539 The default is that any ready insns can be chosen to be issued. 18540 18541 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *, int, rtx, int, 18542 int, int *) 18543 This hook is called by the insn scheduler before issuing insn 18544 passed as the third parameter on given cycle. If the hook returns 18545 nonzero, the insn is not issued on given processors cycle. 18546 Instead of that, the processor cycle is advanced. If the value 18547 passed through the last parameter is zero, the insn ready queue is 18548 not sorted on the new cycle start as usually. The first parameter 18549 passes file for debugging output. The second one passes the 18550 scheduler verbose level of the debugging output. The forth and 18551 the fifth parameter values are correspondingly processor cycle on 18552 which the previous insn has been issued and the current processor 18553 cycle. 18554 18555 -- Target Hook: void TARGET_SCHED_INIT_DFA_BUBBLES (void) 18556 The DFA-based scheduler could take the insertion of nop operations 18557 for better insn scheduling into account. It can be done only if 18558 the multi-pass insn scheduling works (see hook 18559 `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD'). 18560 18561 Let us consider a VLIW processor insn with 3 slots. Each insn can 18562 be placed only in one of the three slots. We have 3 ready insns 18563 A, B, and C. A and C can be placed only in the 1st slot, B can be 18564 placed only in the 3rd slot. We described the automaton which 18565 does not permit empty slot gaps between insns (usually such 18566 description is simpler). Without this code the scheduler would 18567 place each insn in 3 separate VLIW insns. If the scheduler places 18568 a nop insn into the 2nd slot, it could place the 3 insns into 2 18569 VLIW insns. What is the nop insn is returned by hook 18570 `TARGET_SCHED_DFA_BUBBLE'. Hook `TARGET_SCHED_INIT_DFA_BUBBLES' 18571 can be used to initialize or create the nop insns. 18572 18573 You should remember that the scheduler does not insert the nop 18574 insns. It is not wise because of the following optimizations. 18575 The scheduler only considers such possibility to improve the 18576 result schedule. The nop insns should be inserted lately, e.g. on 18577 the final phase. 18578 18579 -- Target Hook: rtx TARGET_SCHED_DFA_BUBBLE (int INDEX) 18580 This hook `FIRST_CYCLE_MULTIPASS_SCHEDULING' is used to insert nop 18581 operations for better insn scheduling when DFA-based scheduler 18582 makes multipass insn scheduling (see also description of hook 18583 `TARGET_SCHED_INIT_DFA_BUBBLES'). This hook returns a nop insn 18584 with given INDEX. The indexes start with zero. The hook should 18585 return `NULL' if there are no more nop insns with indexes greater 18586 than given index. 18587 18588 -- Target Hook: bool IS_COSTLY_DEPENDENCE (rtx INSN1, rtx INSN2, rtx 18589 DEP_LINK, int DEP_COST, int DISTANCE) 18590 This hook is used to define which dependences are considered 18591 costly by the target, so costly that it is not advisable to 18592 schedule the insns that are involved in the dependence too close 18593 to one another. The parameters to this hook are as follows: The 18594 second parameter INSN2 is dependent upon the first parameter 18595 INSN1. The dependence between INSN1 and INSN2 is represented by 18596 the third parameter DEP_LINK. The fourth parameter COST is the 18597 cost of the dependence, and the fifth parameter DISTANCE is the 18598 distance in cycles between the two insns. The hook returns `true' 18599 if considering the distance between the two insns the dependence 18600 between them is considered costly by the target, and `false' 18601 otherwise. 18602 18603 Defining this hook can be useful in multiple-issue out-of-order 18604 machines, where (a) it's practically hopeless to predict the 18605 actual data/resource delays, however: (b) there's a better chance 18606 to predict the actual grouping that will be formed, and (c) 18607 correctly emulating the grouping can be very important. In such 18608 targets one may want to allow issuing dependent insns closer to 18609 one another - i.e, closer than the dependence distance; however, 18610 not in cases of "costly dependences", which this hooks allows to 18611 define. 18612 18613 Macros in the following table are generated by the program `genattr' 18614and can be useful for writing the hooks. 18615 18616 -- Macro: TRADITIONAL_PIPELINE_INTERFACE 18617 The macro definition is generated if there is a traditional 18618 pipeline description in `.md' file. You should also remember that 18619 to simplify the insn scheduler sources an empty traditional 18620 pipeline description interface is generated even if there is no a 18621 traditional pipeline description in the `.md' file. The macro can 18622 be used to distinguish the two types of the traditional interface. 18623 18624 -- Macro: DFA_PIPELINE_INTERFACE 18625 The macro definition is generated if there is an automaton pipeline 18626 description in `.md' file. You should also remember that to 18627 simplify the insn scheduler sources an empty automaton pipeline 18628 description interface is generated even if there is no an automaton 18629 pipeline description in the `.md' file. The macro can be used to 18630 distinguish the two types of the automaton interface. 18631 18632 -- Macro: MAX_DFA_ISSUE_RATE 18633 The macro definition is generated in the automaton based pipeline 18634 description interface. Its value is calculated from the automaton 18635 based pipeline description and is equal to maximal number of all 18636 insns described in constructions `define_insn_reservation' which 18637 can be issued on the same processor cycle. 18638 18639 18640File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 18641 1864211.18 Dividing the Output into Sections (Texts, Data, ...) 18643========================================================== 18644 18645An object file is divided into sections containing different types of 18646data. In the most common case, there are three sections: the "text 18647section", which holds instructions and read-only data; the "data 18648section", which holds initialized writable data; and the "bss section", 18649which holds uninitialized data. Some systems have other kinds of 18650sections. 18651 18652 The compiler must tell the assembler when to switch sections. These 18653macros control what commands to output to tell the assembler this. You 18654can also define additional sections. 18655 18656 -- Macro: TEXT_SECTION_ASM_OP 18657 A C expression whose value is a string, including spacing, 18658 containing the assembler operation that should precede 18659 instructions and read-only data. Normally `"\t.text"' is right. 18660 18661 -- Macro: HOT_TEXT_SECTION_NAME 18662 If defined, a C string constant for the name of the section 18663 containing most frequently executed functions of the program. If 18664 not defined, GCC will provide a default definition if the target 18665 supports named sections. 18666 18667 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 18668 If defined, a C string constant for the name of the section 18669 containing unlikely executed functions in the program. 18670 18671 -- Macro: DATA_SECTION_ASM_OP 18672 A C expression whose value is a string, including spacing, 18673 containing the assembler operation to identify the following data 18674 as writable initialized data. Normally `"\t.data"' is right. 18675 18676 -- Macro: READONLY_DATA_SECTION_ASM_OP 18677 A C expression whose value is a string, including spacing, 18678 containing the assembler operation to identify the following data 18679 as read-only initialized data. 18680 18681 -- Macro: READONLY_DATA_SECTION 18682 A macro naming a function to call to switch to the proper section 18683 for read-only data. The default is to use 18684 `READONLY_DATA_SECTION_ASM_OP' if defined, else fall back to 18685 `text_section'. 18686 18687 The most common definition will be `data_section', if the target 18688 does not have a special read-only data section, and does not put 18689 data in the text section. 18690 18691 -- Macro: SHARED_SECTION_ASM_OP 18692 If defined, a C expression whose value is a string, including 18693 spacing, containing the assembler operation to identify the 18694 following data as shared data. If not defined, 18695 `DATA_SECTION_ASM_OP' will be used. 18696 18697 -- Macro: BSS_SECTION_ASM_OP 18698 If defined, a C expression whose value is a string, including 18699 spacing, containing the assembler operation to identify the 18700 following data as uninitialized global data. If not defined, and 18701 neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined, 18702 uninitialized global data will be output in the data section if 18703 `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be 18704 used. 18705 18706 -- Macro: INIT_SECTION_ASM_OP 18707 If defined, a C expression whose value is a string, including 18708 spacing, containing the assembler operation to identify the 18709 following data as initialization code. If not defined, GCC will 18710 assume such a section does not exist. 18711 18712 -- Macro: FINI_SECTION_ASM_OP 18713 If defined, a C expression whose value is a string, including 18714 spacing, containing the assembler operation to identify the 18715 following data as finalization code. If not defined, GCC will 18716 assume such a section does not exist. 18717 18718 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 18719 If defined, an ASM statement that switches to a different section 18720 via SECTION_OP, calls FUNCTION, and switches back to the text 18721 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or 18722 `FINI_SECTION_ASM_OP' to calls to initialization and finalization 18723 functions from the init and fini sections. By default, this macro 18724 uses a simple function call. Some ports need hand-crafted 18725 assembly code to avoid dependencies on registers initialized in 18726 the function prologue or to ensure that constant pools don't end 18727 up too far way in the text section. 18728 18729 -- Macro: FORCE_CODE_SECTION_ALIGN 18730 If defined, an ASM statement that aligns a code section to some 18731 arbitrary boundary. This is used to force all fragments of the 18732 `.init' and `.fini' sections to have to same alignment and thus 18733 prevent the linker from having to add any padding. 18734 18735 -- Macro: EXTRA_SECTIONS 18736 A list of names for sections other than the standard two, which are 18737 `in_text' and `in_data'. You need not define this macro on a 18738 system with no other sections (that GCC needs to use). 18739 18740 -- Macro: EXTRA_SECTION_FUNCTIONS 18741 One or more functions to be defined in `varasm.c'. These 18742 functions should do jobs analogous to those of `text_section' and 18743 `data_section', for your additional sections. Do not define this 18744 macro if you do not define `EXTRA_SECTIONS'. 18745 18746 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 18747 Define this macro to be an expression with a nonzero value if jump 18748 tables (for `tablejump' insns) should be output in the text 18749 section, along with the assembler instructions. Otherwise, the 18750 readonly data section is used. 18751 18752 This macro is irrelevant if there is no separate readonly data 18753 section. 18754 18755 -- Target Hook: void TARGET_ASM_SELECT_SECTION (tree EXP, int RELOC, 18756 unsigned HOST_WIDE_INT ALIGN) 18757 Switches to the appropriate section for output of EXP. You can 18758 assume that EXP is either a `VAR_DECL' node or a constant of some 18759 sort. RELOC indicates whether the initial value of EXP requires 18760 link-time relocations. Bit 0 is set when variable contains local 18761 relocations only, while bit 1 is set for global relocations. 18762 Select the section by calling `data_section' or one of the 18763 alternatives for other sections. ALIGN is the constant alignment 18764 in bits. 18765 18766 The default version of this function takes care of putting 18767 read-only variables in `readonly_data_section'. 18768 18769 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 18770 Build up a unique section name, expressed as a `STRING_CST' node, 18771 and assign it to `DECL_SECTION_NAME (DECL)'. As with 18772 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 18773 value of EXP requires link-time relocations. 18774 18775 The default version of this function appends the symbol name to the 18776 ELF section name that would normally be used for the symbol. For 18777 example, the function `foo' would be placed in `.text.foo'. 18778 Whatever the actual target object format, this is often good 18779 enough. 18780 18781 -- Target Hook: void TARGET_ASM_SELECT_RTX_SECTION (enum machine_mode 18782 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 18783 Switches to the appropriate section for output of constant pool 18784 entry X in MODE. You can assume that X is some kind of constant 18785 in RTL. The argument MODE is redundant except in the case of a 18786 `const_int' rtx. Select the section by calling 18787 `readonly_data_section' or one of the alternatives for other 18788 sections. ALIGN is the constant alignment in bits. 18789 18790 The default version of this function takes care of putting symbolic 18791 constants in `flag_pic' mode in `data_section' and everything else 18792 in `readonly_data_section'. 18793 18794 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 18795 int NEW_DECL_P) 18796 Define this hook if references to a symbol or a constant must be 18797 treated differently depending on something about the variable or 18798 function named by the symbol (such as what section it is in). 18799 18800 The hook is executed immediately after rtl has been created for 18801 DECL, which may be a variable or function declaration or an entry 18802 in the constant pool. In either case, RTL is the rtl in question. 18803 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not 18804 have been initialized yet. 18805 18806 In the case of a constant, it is safe to assume that the rtl is a 18807 `mem' whose address is a `symbol_ref'. Most decls will also have 18808 this form, but that is not guaranteed. Global register variables, 18809 for instance, will have a `reg' for their rtl. (Normally the 18810 right thing to do with such unusual rtl is leave it alone.) 18811 18812 The NEW_DECL_P argument will be true if this is the first time 18813 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. 18814 It will be false for subsequent invocations, which will happen for 18815 duplicate declarations. Whether or not anything must be done for 18816 the duplicate declaration depends on whether the hook examines 18817 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 18818 called for a constant. 18819 18820 The usual thing for this hook to do is to record flags in the 18821 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'. 18822 Historically, the name string was modified if it was necessary to 18823 encode more than one bit of information, but this practice is now 18824 discouraged; use `SYMBOL_REF_FLAGS'. 18825 18826 The default definition of this hook, `default_encode_section_info' 18827 in `varasm.c', sets a number of commonly-useful bits in 18828 `SYMBOL_REF_FLAGS'. Check whether the default does what you need 18829 before overriding it. 18830 18831 -- Target Hook: const char *TARGET_STRIP_NAME_ENCODING (const char 18832 *name) 18833 Decode NAME and return the real name part, sans the characters 18834 that `TARGET_ENCODE_SECTION_INFO' may have added. 18835 18836 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (tree EXP) 18837 Returns true if EXP should be placed into a "small data" section. 18838 The default version of this hook always returns false. 18839 18840 -- Variable: Target Hook bool TARGET_HAVE_SRODATA_SECTION 18841 Contains the value true if the target places read-only "small 18842 data" into a separate section. The default value is false. 18843 18844 -- Target Hook: bool TARGET_BINDS_LOCAL_P (tree EXP) 18845 Returns true if EXP names an object for which name resolution 18846 rules must resolve to the current "module" (dynamic shared library 18847 or executable image). 18848 18849 The default version of this hook implements the name resolution 18850 rules for ELF, which has a looser model of global name binding 18851 than other currently supported object file formats. 18852 18853 -- Variable: Target Hook bool TARGET_HAVE_TLS 18854 Contains the value true if the target supports thread-local 18855 storage. The default value is false. 18856 18857 18858File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 18859 1886011.19 Position Independent Code 18861=============================== 18862 18863This section describes macros that help implement generation of position 18864independent code. Simply defining these macros is not enough to 18865generate valid PIC; you must also add support to the macros 18866`GO_IF_LEGITIMATE_ADDRESS' and `PRINT_OPERAND_ADDRESS', as well as 18867`LEGITIMIZE_ADDRESS'. You must modify the definition of `movsi' to do 18868something appropriate when the source operand contains a symbolic 18869address. You may also need to alter the handling of switch statements 18870so that they use relative addresses. 18871 18872 -- Macro: PIC_OFFSET_TABLE_REGNUM 18873 The register number of the register used to address a table of 18874 static data addresses in memory. In some cases this register is 18875 defined by a processor's "application binary interface" (ABI). 18876 When this macro is defined, RTL is generated for this register 18877 once, as with the stack pointer and frame pointer registers. If 18878 this macro is not defined, it is up to the machine-dependent files 18879 to allocate such a register (if necessary). Note that this 18880 register must be fixed when in use (e.g. when `flag_pic' is true). 18881 18882 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 18883 Define this macro if the register defined by 18884 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define 18885 this macro if `PIC_OFFSET_TABLE_REGNUM' is not defined. 18886 18887 -- Macro: FINALIZE_PIC 18888 By generating position-independent code, when two different 18889 programs (A and B) share a common library (libC.a), the text of 18890 the library can be shared whether or not the library is linked at 18891 the same address for both programs. In some of these 18892 environments, position-independent code requires not only the use 18893 of different addressing modes, but also special code to enable the 18894 use of these addressing modes. 18895 18896 The `FINALIZE_PIC' macro serves as a hook to emit these special 18897 codes once the function is being compiled into assembly code, but 18898 not before. (It is not done before, because in the case of 18899 compiling an inline function, it would lead to multiple PIC 18900 prologues being included in functions which used inline functions 18901 and were compiled to assembly language.) 18902 18903 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 18904 A C expression that is nonzero if X is a legitimate immediate 18905 operand on the target machine when generating position independent 18906 code. You can assume that X satisfies `CONSTANT_P', so you need 18907 not check this. You can also assume FLAG_PIC is true, so you need 18908 not check it either. You need not define this macro if all 18909 constants (including `SYMBOL_REF') can be immediate operands when 18910 generating position independent code. 18911 18912 18913File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 18914 1891511.20 Defining the Output Assembler Language 18916============================================ 18917 18918This section describes macros whose principal purpose is to describe how 18919to write instructions in assembler language--rather than what the 18920instructions do. 18921 18922* Menu: 18923 18924* File Framework:: Structural information for the assembler file. 18925* Data Output:: Output of constants (numbers, strings, addresses). 18926* Uninitialized Data:: Output of uninitialized variables. 18927* Label Output:: Output and generation of labels. 18928* Initialization:: General principles of initialization 18929 and termination routines. 18930* Macros for Initialization:: 18931 Specific macros that control the handling of 18932 initialization and termination routines. 18933* Instruction Output:: Output of actual instructions. 18934* Dispatch Tables:: Output of jump tables. 18935* Exception Region Output:: Output of exception region code. 18936* Alignment Output:: Pseudo ops for alignment and skipping data. 18937 18938 18939File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 18940 1894111.20.1 The Overall Framework of an Assembler File 18942-------------------------------------------------- 18943 18944This describes the overall framework of an assembly file. 18945 18946 -- Target Hook: void TARGET_ASM_FILE_START () 18947 Output to `asm_out_file' any text which the assembler expects to 18948 find at the beginning of a file. The default behavior is 18949 controlled by two flags, documented below. Unless your target's 18950 assembler is quite unusual, if you override the default, you 18951 should call `default_file_start' at some point in your target 18952 hook. This lets other target files rely on these variables. 18953 18954 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 18955 If this flag is true, the text of the macro `ASM_APP_OFF' will be 18956 printed as the very first line in the assembly file, unless 18957 `-fverbose-asm' is in effect. (If that macro has been defined to 18958 the empty string, this variable has no effect.) With the normal 18959 definition of `ASM_APP_OFF', the effect is to notify the GNU 18960 assembler that it need not bother stripping comments or extra 18961 whitespace from its input. This allows it to work a bit faster. 18962 18963 The default is false. You should not set it to true unless you 18964 have verified that your port does not generate any extra 18965 whitespace or comments that will cause GAS to issue errors in 18966 NO_APP mode. 18967 18968 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 18969 If this flag is true, `output_file_directive' will be called for 18970 the primary source file, immediately after printing `ASM_APP_OFF' 18971 (if that is enabled). Most ELF assemblers expect this to be done. 18972 The default is false. 18973 18974 -- Target Hook: void TARGET_ASM_FILE_END () 18975 Output to `asm_out_file' any text which the assembler expects to 18976 find at the end of a file. The default is to output nothing. 18977 18978 -- Function: void file_end_indicate_exec_stack () 18979 Some systems use a common convention, the `.note.GNU-stack' 18980 special section, to indicate whether or not an object file relies 18981 on the stack being executable. If your system uses this 18982 convention, you should define `TARGET_ASM_FILE_END' to this 18983 function. If you need to do other things in that hook, have your 18984 hook function call this function. 18985 18986 -- Macro: ASM_COMMENT_START 18987 A C string constant describing how to begin a comment in the target 18988 assembler language. The compiler assumes that the comment will 18989 end at the end of the line. 18990 18991 -- Macro: ASM_APP_ON 18992 A C string constant for text to be output before each `asm' 18993 statement or group of consecutive ones. Normally this is 18994 `"#APP"', which is a comment that has no effect on most assemblers 18995 but tells the GNU assembler that it must check the lines that 18996 follow for all valid assembler constructs. 18997 18998 -- Macro: ASM_APP_OFF 18999 A C string constant for text to be output after each `asm' 19000 statement or group of consecutive ones. Normally this is 19001 `"#NO_APP"', which tells the GNU assembler to resume making the 19002 time-saving assumptions that are valid for ordinary compiler 19003 output. 19004 19005 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 19006 A C statement to output COFF information or DWARF debugging 19007 information which indicates that filename NAME is the current 19008 source file to the stdio stream STREAM. 19009 19010 This macro need not be defined if the standard form of output for 19011 the file format in use is appropriate. 19012 19013 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 19014 A C statement to output the string STRING to the stdio stream 19015 STREAM. If you do not call the function `output_quoted_string' in 19016 your config files, GCC will only call it to output filenames to 19017 the assembler source. So you can use it to canonicalize the format 19018 of the filename using this macro. 19019 19020 -- Macro: ASM_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 19021 A C statement to output DBX or SDB debugging information before 19022 code for line number LINE of the current source file to the stdio 19023 stream STREAM. COUNTER is the number of time the macro was 19024 invoked, including the current invocation; it is intended to 19025 generate unique labels in the assembly output. 19026 19027 This macro need not be defined if the standard form of debugging 19028 information for the debugger in use is appropriate. 19029 19030 -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING) 19031 A C statement to output something to the assembler file to handle a 19032 `#ident' directive containing the text STRING. If this macro is 19033 not defined, nothing is output for a `#ident' directive. 19034 19035 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 19036 unsigned int FLAGS, unsigned int ALIGN) 19037 Output assembly directives to switch to section NAME. The section 19038 should have attributes as specified by FLAGS, which is a bit mask 19039 of the `SECTION_*' flags defined in `output.h'. If ALIGN is 19040 nonzero, it contains an alignment in bytes to be used for the 19041 section, otherwise some target default should be used. Only 19042 targets that must specify an alignment within the section 19043 directive need pay attention to ALIGN - we will still use 19044 `ASM_OUTPUT_ALIGN'. 19045 19046 -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 19047 This flag is true if the target supports 19048 `TARGET_ASM_NAMED_SECTION'. 19049 19050 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 19051 const char *NAME, int RELOC) 19052 Choose a set of section attributes for use by 19053 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 19054 section name, and whether or not the declaration's initializer may 19055 contain runtime relocations. DECL may be null, in which case 19056 read-write data should be assumed. 19057 19058 The default version if this function handles choosing code vs data, 19059 read-only vs read-write data, and `flag_pic'. You should only 19060 need to override this if your target has special flags that might 19061 be set via `__attribute__'. 19062 19063 19064File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 19065 1906611.20.2 Output of Data 19067---------------------- 19068 19069 -- Target Hook: const char * TARGET_ASM_BYTE_OP 19070 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 19071 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 19072 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 19073 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 19074 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 19075 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 19076 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 19077 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 19078 These hooks specify assembly directives for creating certain kinds 19079 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a 19080 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an 19081 aligned two-byte object, and so on. Any of the hooks may be 19082 `NULL', indicating that no suitable directive is available. 19083 19084 The compiler will print these strings at the start of a new line, 19085 followed immediately by the object's initial value. In most cases, 19086 the string should contain a tab, a pseudo-op, and then another tab. 19087 19088 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 19089 ALIGNED_P) 19090 The `assemble_integer' function uses this hook to output an 19091 integer object. X is the object's value, SIZE is its size in 19092 bytes and ALIGNED_P indicates whether it is aligned. The function 19093 should return `true' if it was able to output the object. If it 19094 returns false, `assemble_integer' will try to split the object 19095 into smaller parts. 19096 19097 The default implementation of this hook will use the 19098 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the 19099 relevant string is `NULL'. 19100 19101 -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL) 19102 A C statement to recognize RTX patterns that `output_addr_const' 19103 can't deal with, and output assembly code to STREAM corresponding 19104 to the pattern X. This may be used to allow machine-dependent 19105 `UNSPEC's to appear within constants. 19106 19107 If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must 19108 `goto fail', so that a standard error message is printed. If it 19109 prints an error message itself, by calling, for example, 19110 `output_operand_lossage', it may just complete normally. 19111 19112 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 19113 A C statement to output to the stdio stream STREAM an assembler 19114 instruction to assemble a string constant containing the LEN bytes 19115 at PTR. PTR will be a C expression of type `char *' and LEN a C 19116 expression of type `int'. 19117 19118 If the assembler has a `.ascii' pseudo-op as found in the Berkeley 19119 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 19120 19121 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 19122 A C statement to output word N of a function descriptor for DECL. 19123 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is 19124 defined, and is otherwise unused. 19125 19126 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 19127 You may define this macro as a C expression. You should define the 19128 expression to have a nonzero value if GCC should output the 19129 constant pool for a function before the code for the function, or 19130 a zero value if GCC should output the constant pool after the 19131 function. If you do not define this macro, the usual case, GCC 19132 will output the constant pool before the function. 19133 19134 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 19135 A C statement to output assembler commands to define the start of 19136 the constant pool for a function. FUNNAME is a string giving the 19137 name of the function. Should the return type of the function be 19138 required, it can be obtained via FUNDECL. SIZE is the size, in 19139 bytes, of the constant pool that will be written immediately after 19140 this call. 19141 19142 If no constant-pool prefix is required, the usual case, this macro 19143 need not be defined. 19144 19145 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, 19146 LABELNO, JUMPTO) 19147 A C statement (with or without semicolon) to output a constant in 19148 the constant pool, if it needs special treatment. (This macro 19149 need not do anything for RTL expressions that can be output 19150 normally.) 19151 19152 The argument FILE is the standard I/O stream to output the 19153 assembler code on. X is the RTL expression for the constant to 19154 output, and MODE is the machine mode (in case X is a `const_int'). 19155 ALIGN is the required alignment for the value X; you should 19156 output an assembler directive to force this much alignment. 19157 19158 The argument LABELNO is a number to use in an internal label for 19159 the address of this pool entry. The definition of this macro is 19160 responsible for outputting the label definition at the proper 19161 place. Here is how to do this: 19162 19163 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO); 19164 19165 When you output a pool entry specially, you should end with a 19166 `goto' to the label JUMPTO. This will prevent the same pool entry 19167 from being output a second time in the usual manner. 19168 19169 You need not define this macro if it would do nothing. 19170 19171 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 19172 A C statement to output assembler commands to at the end of the 19173 constant pool for a function. FUNNAME is a string giving the name 19174 of the function. Should the return type of the function be 19175 required, you can obtain it via FUNDECL. SIZE is the size, in 19176 bytes, of the constant pool that GCC wrote immediately before this 19177 call. 19178 19179 If no constant-pool epilogue is required, the usual case, you need 19180 not define this macro. 19181 19182 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C) 19183 Define this macro as a C expression which is nonzero if C is used 19184 as a logical line separator by the assembler. 19185 19186 If you do not define this macro, the default is that only the 19187 character `;' is treated as a logical line separator. 19188 19189 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 19190 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 19191 These target hooks are C string constants, describing the syntax 19192 in the assembler for grouping arithmetic expressions. If not 19193 overridden, they default to normal parentheses, which is correct 19194 for most assemblers. 19195 19196 These macros are provided by `real.h' for writing the definitions of 19197`ASM_OUTPUT_DOUBLE' and the like: 19198 19199 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 19200 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 19201 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 19202 These translate X, of type `REAL_VALUE_TYPE', to the target's 19203 floating point representation, and store its bit pattern in the 19204 variable L. For `REAL_VALUE_TO_TARGET_SINGLE', this variable 19205 should be a simple `long int'. For the others, it should be an 19206 array of `long int'. The number of elements in this array is 19207 determined by the size of the desired target floating point data 19208 type: 32 bits of it go in each `long int' array element. Each 19209 array element holds 32 bits of the result, even if `long int' is 19210 wider than 32 bits on the host machine. 19211 19212 The array element values are designed so that you can print them 19213 out using `fprintf' in the order they should appear in the target 19214 machine's memory. 19215 19216 19217File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 19218 1921911.20.3 Output of Uninitialized Variables 19220----------------------------------------- 19221 19222Each of the macros in this section is used to do the whole job of 19223outputting a single uninitialized variable. 19224 19225 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 19226 A C statement (sans semicolon) to output to the stdio stream 19227 STREAM the assembler definition of a common-label named NAME whose 19228 size is SIZE bytes. The variable ROUNDED is the size rounded up 19229 to whatever alignment the caller wants. 19230 19231 Use the expression `assemble_name (STREAM, NAME)' to output the 19232 name itself; before and after that, output the additional 19233 assembler syntax for defining the name, and a newline. 19234 19235 This macro controls how the assembler definitions of uninitialized 19236 common global variables are output. 19237 19238 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 19239 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a 19240 separate, explicit argument. If you define this macro, it is used 19241 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in 19242 handling the required alignment of the variable. The alignment is 19243 specified as the number of bits. 19244 19245 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 19246 ALIGNMENT) 19247 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 19248 to be output, if there is one, or `NULL_TREE' if there is no 19249 corresponding variable. If you define this macro, GCC will use it 19250 in place of both `ASM_OUTPUT_COMMON' and 19251 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 19252 see the variable's decl in order to chose what to output. 19253 19254 -- Macro: ASM_OUTPUT_SHARED_COMMON (STREAM, NAME, SIZE, ROUNDED) 19255 If defined, it is similar to `ASM_OUTPUT_COMMON', except that it 19256 is used when NAME is shared. If not defined, `ASM_OUTPUT_COMMON' 19257 will be used. 19258 19259 -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED) 19260 A C statement (sans semicolon) to output to the stdio stream 19261 STREAM the assembler definition of uninitialized global DECL named 19262 NAME whose size is SIZE bytes. The variable ROUNDED is the size 19263 rounded up to whatever alignment the caller wants. 19264 19265 Try to use function `asm_output_bss' defined in `varasm.c' when 19266 defining this macro. If unable, use the expression `assemble_name 19267 (STREAM, NAME)' to output the name itself; before and after that, 19268 output the additional assembler syntax for defining the name, and 19269 a newline. 19270 19271 This macro controls how the assembler definitions of uninitialized 19272 global variables are output. This macro exists to properly 19273 support languages like C++ which do not have `common' data. 19274 However, this macro currently is not defined for all targets. If 19275 this macro and `ASM_OUTPUT_ALIGNED_BSS' are not defined then 19276 `ASM_OUTPUT_COMMON' or `ASM_OUTPUT_ALIGNED_COMMON' or 19277 `ASM_OUTPUT_ALIGNED_DECL_COMMON' is used. 19278 19279 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 19280 Like `ASM_OUTPUT_BSS' except takes the required alignment as a 19281 separate, explicit argument. If you define this macro, it is used 19282 in place of `ASM_OUTPUT_BSS', and gives you more flexibility in 19283 handling the required alignment of the variable. The alignment is 19284 specified as the number of bits. 19285 19286 Try to use function `asm_output_aligned_bss' defined in file 19287 `varasm.c' when defining this macro. 19288 19289 -- Macro: ASM_OUTPUT_SHARED_BSS (STREAM, DECL, NAME, SIZE, ROUNDED) 19290 If defined, it is similar to `ASM_OUTPUT_BSS', except that it is 19291 used when NAME is shared. If not defined, `ASM_OUTPUT_BSS' will 19292 be used. 19293 19294 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 19295 A C statement (sans semicolon) to output to the stdio stream 19296 STREAM the assembler definition of a local-common-label named NAME 19297 whose size is SIZE bytes. The variable ROUNDED is the size 19298 rounded up to whatever alignment the caller wants. 19299 19300 Use the expression `assemble_name (STREAM, NAME)' to output the 19301 name itself; before and after that, output the additional 19302 assembler syntax for defining the name, and a newline. 19303 19304 This macro controls how the assembler definitions of uninitialized 19305 static variables are output. 19306 19307 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 19308 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a 19309 separate, explicit argument. If you define this macro, it is used 19310 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in 19311 handling the required alignment of the variable. The alignment is 19312 specified as the number of bits. 19313 19314 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 19315 ALIGNMENT) 19316 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 19317 be output, if there is one, or `NULL_TREE' if there is no 19318 corresponding variable. If you define this macro, GCC will use it 19319 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'. 19320 Define this macro when you need to see the variable's decl in 19321 order to chose what to output. 19322 19323 -- Macro: ASM_OUTPUT_SHARED_LOCAL (STREAM, NAME, SIZE, ROUNDED) 19324 If defined, it is similar to `ASM_OUTPUT_LOCAL', except that it is 19325 used when NAME is shared. If not defined, `ASM_OUTPUT_LOCAL' will 19326 be used. 19327 19328 19329File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 19330 1933111.20.4 Output and Generation of Labels 19332--------------------------------------- 19333 19334This is about outputting labels. 19335 19336 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 19337 A C statement (sans semicolon) to output to the stdio stream 19338 STREAM the assembler definition of a label named NAME. Use the 19339 expression `assemble_name (STREAM, NAME)' to output the name 19340 itself; before and after that, output the additional assembler 19341 syntax for defining the name, and a newline. A default definition 19342 of this macro is provided which is correct for most systems. 19343 19344 -- Macro: SIZE_ASM_OP 19345 A C string containing the appropriate assembler directive to 19346 specify the size of a symbol, without any arguments. On systems 19347 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"'; 19348 on other systems, the default is not to define this macro. 19349 19350 Define this macro only if it is correct to use the default 19351 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and 19352 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 19353 custom definitions of those macros, or if you do not need explicit 19354 symbol sizes at all, do not define this macro. 19355 19356 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 19357 A C statement (sans semicolon) to output to the stdio stream 19358 STREAM a directive telling the assembler that the size of the 19359 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define 19360 `SIZE_ASM_OP', a default definition of this macro is provided. 19361 19362 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 19363 A C statement (sans semicolon) to output to the stdio stream 19364 STREAM a directive telling the assembler to calculate the size of 19365 the symbol NAME by subtracting its address from the current 19366 address. 19367 19368 If you define `SIZE_ASM_OP', a default definition of this macro is 19369 provided. The default assumes that the assembler recognizes a 19370 special `.' symbol as referring to the current address, and can 19371 calculate the difference between this and another symbol. If your 19372 assembler does not recognize `.' or cannot do calculations with 19373 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use 19374 some other technique. 19375 19376 -- Macro: TYPE_ASM_OP 19377 A C string containing the appropriate assembler directive to 19378 specify the type of a symbol, without any arguments. On systems 19379 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"'; 19380 on other systems, the default is not to define this macro. 19381 19382 Define this macro only if it is correct to use the default 19383 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 19384 need your own custom definition of this macro, or if you do not 19385 need explicit symbol types at all, do not define this macro. 19386 19387 -- Macro: TYPE_OPERAND_FMT 19388 A C string which specifies (using `printf' syntax) the format of 19389 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the 19390 default (in `config/elfos.h') is `"@%s"'; on other systems, the 19391 default is not to define this macro. 19392 19393 Define this macro only if it is correct to use the default 19394 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 19395 need your own custom definition of this macro, or if you do not 19396 need explicit symbol types at all, do not define this macro. 19397 19398 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 19399 A C statement (sans semicolon) to output to the stdio stream 19400 STREAM a directive telling the assembler that the type of the 19401 symbol NAME is TYPE. TYPE is a C string; currently, that string 19402 is always either `"function"' or `"object"', but you should not 19403 count on this. 19404 19405 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default 19406 definition of this macro is provided. 19407 19408 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 19409 A C statement (sans semicolon) to output to the stdio stream 19410 STREAM any text necessary for declaring the name NAME of a 19411 function which is being defined. This macro is responsible for 19412 outputting the label definition (perhaps using 19413 `ASM_OUTPUT_LABEL'). The argument DECL is the `FUNCTION_DECL' 19414 tree node representing the function. 19415 19416 If this macro is not defined, then the function name is defined in 19417 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 19418 19419 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 19420 of this macro. 19421 19422 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 19423 A C statement (sans semicolon) to output to the stdio stream 19424 STREAM any text necessary for declaring the size of a function 19425 which is being defined. The argument NAME is the name of the 19426 function. The argument DECL is the `FUNCTION_DECL' tree node 19427 representing the function. 19428 19429 If this macro is not defined, then the function size is not 19430 defined. 19431 19432 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition 19433 of this macro. 19434 19435 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 19436 A C statement (sans semicolon) to output to the stdio stream 19437 STREAM any text necessary for declaring the name NAME of an 19438 initialized variable which is being defined. This macro must 19439 output the label definition (perhaps using `ASM_OUTPUT_LABEL'). 19440 The argument DECL is the `VAR_DECL' tree node representing the 19441 variable. 19442 19443 If this macro is not defined, then the variable name is defined in 19444 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 19445 19446 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or 19447 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 19448 19449 -- Macro: ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE) 19450 A C statement (sans semicolon) to output to the stdio stream 19451 STREAM any text necessary for declaring the name NAME of a 19452 constant which is being defined. This macro is responsible for 19453 outputting the label definition (perhaps using 19454 `ASM_OUTPUT_LABEL'). The argument EXP is the value of the 19455 constant, and SIZE is the size of the constant in bytes. NAME 19456 will be an internal label. 19457 19458 If this macro is not defined, then the NAME is defined in the 19459 usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 19460 19461 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 19462 of this macro. 19463 19464 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 19465 A C statement (sans semicolon) to output to the stdio stream 19466 STREAM any text necessary for claiming a register REGNO for a 19467 global variable DECL with name NAME. 19468 19469 If you don't define this macro, that is equivalent to defining it 19470 to do nothing. 19471 19472 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 19473 A C statement (sans semicolon) to finish up declaring a variable 19474 name once the compiler has processed its initializer fully and 19475 thus has had a chance to determine the size of an array when 19476 controlled by an initializer. This is used on systems where it's 19477 necessary to declare something about the size of the object. 19478 19479 If you don't define this macro, that is equivalent to defining it 19480 to do nothing. 19481 19482 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or 19483 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 19484 19485 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 19486 char *NAME) 19487 This target hook is a function to output to the stdio stream 19488 STREAM some commands that will make the label NAME global; that 19489 is, available for reference from other files. 19490 19491 The default implementation relies on a proper definition of 19492 `GLOBAL_ASM_OP'. 19493 19494 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 19495 A C statement (sans semicolon) to output to the stdio stream 19496 STREAM some commands that will make the label NAME weak; that is, 19497 available for reference from other files but only used if no other 19498 definition is available. Use the expression `assemble_name 19499 (STREAM, NAME)' to output the name itself; before and after that, 19500 output the additional assembler syntax for making that name weak, 19501 and a newline. 19502 19503 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not 19504 support weak symbols and you should not define the `SUPPORTS_WEAK' 19505 macro. 19506 19507 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 19508 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and 19509 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 19510 or variable decl. If VALUE is not `NULL', this C statement should 19511 output to the stdio stream STREAM assembler code which defines 19512 (equates) the weak symbol NAME to have the value VALUE. If VALUE 19513 is `NULL', it should output commands to make NAME weak. 19514 19515 -- Macro: SUPPORTS_WEAK 19516 A C expression which evaluates to true if the target supports weak 19517 symbols. 19518 19519 If you don't define this macro, `defaults.h' provides a default 19520 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is 19521 defined, the default definition is `1'; otherwise, it is `0'. 19522 Define this macro if you want to control weak symbol support with 19523 a compiler flag such as `-melf'. 19524 19525 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 19526 A C statement (sans semicolon) to mark DECL to be emitted as a 19527 public symbol such that extra copies in multiple translation units 19528 will be discarded by the linker. Define this macro if your object 19529 file format provides support for this concept, such as the `COMDAT' 19530 section flags in the Microsoft Windows PE/COFF format, and this 19531 support requires changes to DECL, such as putting it in a separate 19532 section. 19533 19534 -- Macro: SUPPORTS_ONE_ONLY 19535 A C expression which evaluates to true if the target supports 19536 one-only semantics. 19537 19538 If you don't define this macro, `varasm.c' provides a default 19539 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default 19540 definition is `1'; otherwise, it is `0'. Define this macro if you 19541 want to control one-only symbol support with a compiler flag, or if 19542 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to 19543 be emitted as one-only. 19544 19545 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, const 19546 char *VISIBILITY) 19547 This target hook is a function to output to ASM_OUT_FILE some 19548 commands that will make the symbol(s) associated with DECL have 19549 hidden, protected or internal visibility as specified by 19550 VISIBILITY. 19551 19552 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 19553 A C statement (sans semicolon) to output to the stdio stream 19554 STREAM any text necessary for declaring the name of an external 19555 symbol named NAME which is referenced in this compilation but not 19556 defined. The value of DECL is the tree node for the declaration. 19557 19558 This macro need not be defined if it does not need to output 19559 anything. The GNU assembler and most Unix assemblers don't 19560 require anything. 19561 19562 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 19563 This target hook is a function to output to ASM_OUT_FILE an 19564 assembler pseudo-op to declare a library function name external. 19565 The name of the library function is given by SYMREF, which is a 19566 `symbol_ref'. 19567 19568 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 19569 A C statement (sans semicolon) to output to the stdio stream 19570 STREAM a reference in assembler syntax to a label named NAME. 19571 This should add `_' to the front of the name, if that is customary 19572 on your operating system, as it is in most Berkeley Unix systems. 19573 This macro is used in `assemble_name'. 19574 19575 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 19576 A C statement (sans semicolon) to output a reference to 19577 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to 19578 output the name of the symbol. This macro may be used to modify 19579 the way a symbol is referenced depending on information encoded by 19580 `TARGET_ENCODE_SECTION_INFO'. 19581 19582 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 19583 A C statement (sans semicolon) to output a reference to BUF, the 19584 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined, 19585 `assemble_name' will be used to output the name of the symbol. 19586 This macro is not used by `output_asm_label', or the `%l' 19587 specifier that calls it; the intention is that this macro should 19588 be set when it is necessary to output a label differently when its 19589 address is being taken. 19590 19591 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 19592 char *PREFIX, unsigned long LABELNO) 19593 A function to output to the stdio stream STREAM a label whose name 19594 is made from the string PREFIX and the number LABELNO. 19595 19596 It is absolutely essential that these labels be distinct from the 19597 labels used for user-level functions and variables. Otherwise, 19598 certain programs will have name conflicts with internal labels. 19599 19600 It is desirable to exclude internal labels from the symbol table 19601 of the object file. Most assemblers have a naming convention for 19602 labels that should be excluded; on many systems, the letter `L' at 19603 the beginning of a label has this effect. You should find out what 19604 convention your system uses, and follow it. 19605 19606 The default version of this function utilizes 19607 ASM_GENERATE_INTERNAL_LABEL. 19608 19609 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 19610 A C statement to output to the stdio stream STREAM a debug info 19611 label whose name is made from the string PREFIX and the number 19612 NUM. This is useful for VLIW targets, where debug info labels may 19613 need to be treated differently than branch target labels. On some 19614 systems, branch target labels must be at the beginning of 19615 instruction bundles, but debug info labels can occur in the middle 19616 of instruction bundles. 19617 19618 If this macro is not defined, then 19619 `(*targetm.asm_out.internal_label)' will be used. 19620 19621 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 19622 A C statement to store into the string STRING a label whose name 19623 is made from the string PREFIX and the number NUM. 19624 19625 This string, when output subsequently by `assemble_name', should 19626 produce the output that `(*targetm.asm_out.internal_label)' would 19627 produce with the same PREFIX and NUM. 19628 19629 If the string begins with `*', then `assemble_name' will output 19630 the rest of the string unchanged. It is often convenient for 19631 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the 19632 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to 19633 output the string, and may change it. (Of course, 19634 `ASM_OUTPUT_LABELREF' is also part of your machine description, so 19635 you should know what it does on your machine.) 19636 19637 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 19638 A C expression to assign to OUTVAR (which is a variable of type 19639 `char *') a newly allocated string made from the string NAME and 19640 the number NUMBER, with some suitable punctuation added. Use 19641 `alloca' to get space for the string. 19642 19643 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to 19644 produce an assembler label for an internal static variable whose 19645 name is NAME. Therefore, the string must be such as to result in 19646 valid assembler code. The argument NUMBER is different each time 19647 this macro is executed; it prevents conflicts between 19648 similarly-named internal static variables in different scopes. 19649 19650 Ideally this string should not be a valid C identifier, to prevent 19651 any conflict with the user's own symbols. Most assemblers allow 19652 periods or percent signs in assembler symbols; putting at least 19653 one of these between the name and the number will suffice. 19654 19655 If this macro is not defined, a default definition will be provided 19656 which is correct for most systems. 19657 19658 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 19659 A C statement to output to the stdio stream STREAM assembler code 19660 which defines (equates) the symbol NAME to have the value VALUE. 19661 19662 If `SET_ASM_OP' is defined, a default definition is provided which 19663 is correct for most systems. 19664 19665 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 19666 DECL_OF_VALUE) 19667 A C statement to output to the stdio stream STREAM assembler code 19668 which defines (equates) the symbol whose tree node is DECL_OF_NAME 19669 to have the value of the tree node DECL_OF_VALUE. This macro will 19670 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if 19671 the tree nodes are available. 19672 19673 If `SET_ASM_OP' is defined, a default definition is provided which 19674 is correct for most systems. 19675 19676 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 19677 A C statement to output to the stdio stream STREAM assembler code 19678 which defines (equates) the weak symbol NAME to have the value 19679 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak 19680 symbol. 19681 19682 Define this macro if the target only supports weak aliases; define 19683 `ASM_OUTPUT_DEF' instead if possible. 19684 19685 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 19686 SEL_NAME) 19687 Define this macro to override the default assembler names used for 19688 Objective-C methods. 19689 19690 The default name is a unique method number followed by the name of 19691 the class (e.g. `_1_Foo'). For methods in categories, the name of 19692 the category is also included in the assembler name (e.g. 19693 `_1_Foo_Bar'). 19694 19695 These names are safe on most systems, but make debugging difficult 19696 since the method's selector is not present in the name. 19697 Therefore, particular systems define other ways of computing names. 19698 19699 BUF is an expression of type `char *' which gives you a buffer in 19700 which to store the name; its length is as long as CLASS_NAME, 19701 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 19702 19703 The argument IS_INST specifies whether the method is an instance 19704 method or a class method; CLASS_NAME is the name of the class; 19705 CAT_NAME is the name of the category (or `NULL' if the method is 19706 not in a category); and SEL_NAME is the name of the selector. 19707 19708 On systems where the assembler can handle quoted names, you can 19709 use this macro to provide more human-readable names. 19710 19711 -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME) 19712 A C statement (sans semicolon) to output to the stdio stream 19713 STREAM commands to declare that the label NAME is an Objective-C 19714 class reference. This is only needed for targets whose linkers 19715 have special support for NeXT-style runtimes. 19716 19717 -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME) 19718 A C statement (sans semicolon) to output to the stdio stream 19719 STREAM commands to declare that the label NAME is an unresolved 19720 Objective-C class reference. This is only needed for targets 19721 whose linkers have special support for NeXT-style runtimes. 19722 19723 19724File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 19725 1972611.20.5 How Initialization Functions Are Handled 19727------------------------------------------------ 19728 19729The compiled code for certain languages includes "constructors" (also 19730called "initialization routines")--functions to initialize data in the 19731program when the program is started. These functions need to be called 19732before the program is "started"--that is to say, before `main' is 19733called. 19734 19735 Compiling some languages generates "destructors" (also called 19736"termination routines") that should be called when the program 19737terminates. 19738 19739 To make the initialization and termination functions work, the 19740compiler must output something in the assembler code to cause those 19741functions to be called at the appropriate time. When you port the 19742compiler to a new system, you need to specify how to do this. 19743 19744 There are two major ways that GCC currently supports the execution of 19745initialization and termination functions. Each way has two variants. 19746Much of the structure is common to all four variations. 19747 19748 The linker must build two lists of these functions--a list of 19749initialization functions, called `__CTOR_LIST__', and a list of 19750termination functions, called `__DTOR_LIST__'. 19751 19752 Each list always begins with an ignored function pointer (which may 19753hold 0, -1, or a count of the function pointers after it, depending on 19754the environment). This is followed by a series of zero or more function 19755pointers to constructors (or destructors), followed by a function 19756pointer containing zero. 19757 19758 Depending on the operating system and its executable file format, 19759either `crtstuff.c' or `libgcc2.c' traverses these lists at startup 19760time and exit time. Constructors are called in reverse order of the 19761list; destructors in forward order. 19762 19763 The best way to handle static constructors works only for object file 19764formats which provide arbitrarily-named sections. A section is set 19765aside for a list of constructors, and another for a list of destructors. 19766Traditionally these are called `.ctors' and `.dtors'. Each object file 19767that defines an initialization function also puts a word in the 19768constructor section to point to that function. The linker accumulates 19769all these words into one contiguous `.ctors' section. Termination 19770functions are handled similarly. 19771 19772 This method will be chosen as the default by `target-def.h' if 19773`TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 19774arbitrary sections, but does support special designated constructor and 19775destructor sections may define `CTORS_SECTION_ASM_OP' and 19776`DTORS_SECTION_ASM_OP' to achieve the same effect. 19777 19778 When arbitrary sections are available, there are two variants, 19779depending upon how the code in `crtstuff.c' is called. On systems that 19780support a ".init" section which is executed at program startup, parts 19781of `crtstuff.c' are compiled into that section. The program is linked 19782by the `gcc' driver like this: 19783 19784 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 19785 19786 The prologue of a function (`__init') appears in the `.init' section 19787of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the 19788function `__fini' in the ".fini" section. Normally these files are 19789provided by the operating system or by the GNU C library, but are 19790provided by GCC for a few targets. 19791 19792 The objects `crtbegin.o' and `crtend.o' are (for most targets) 19793compiled from `crtstuff.c'. They contain, among other things, code 19794fragments within the `.init' and `.fini' sections that branch to 19795routines in the `.text' section. The linker will pull all parts of a 19796section together, which results in a complete `__init' function that 19797invokes the routines we need at startup. 19798 19799 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro 19800properly. 19801 19802 If no init section is available, when GCC compiles any function 19803called `main' (or more accurately, any function designated as a program 19804entry point by the language front end calling `expand_main_function'), 19805it inserts a procedure call to `__main' as the first executable code 19806after the function prologue. The `__main' function is defined in 19807`libgcc2.c' and runs the global constructors. 19808 19809 In file formats that don't support arbitrary sections, there are 19810again two variants. In the simplest variant, the GNU linker (GNU `ld') 19811and an `a.out' format must be used. In this case, 19812`TARGET_ASM_CONSTRUCTOR' is defined to produce a `.stabs' entry of type 19813`N_SETT', referencing the name `__CTOR_LIST__', and with the address of 19814the void function containing the initialization code as its value. The 19815GNU linker recognizes this as a request to add the value to a "set"; 19816the values are accumulated, and are eventually placed in the executable 19817as a vector in the format described above, with a leading (ignored) 19818count and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled 19819similarly. Since no init section is available, the absence of 19820`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' 19821as above, starting the initialization process. 19822 19823 The last variant uses neither arbitrary sections nor the GNU linker. 19824This is preferable when you want to do dynamic linking and when using 19825file formats which the GNU linker does not support, such as `ECOFF'. In 19826this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and 19827termination functions are recognized simply by their names. This 19828requires an extra program in the linkage step, called `collect2'. This 19829program pretends to be the linker, for use with GCC; it does its job by 19830running the ordinary linker, but also arranges to include the vectors of 19831initialization and termination functions. These functions are called 19832via `__main' as described above. In order to use this method, 19833`use_collect2' must be defined in the target in `config.gcc'. 19834 19835 The following section describes the specific macros that control and 19836customize the handling of initialization and termination functions. 19837 19838 19839File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 19840 1984111.20.6 Macros Controlling Initialization Routines 19842-------------------------------------------------- 19843 19844Here are the macros that control how the compiler handles initialization 19845and termination functions: 19846 19847 -- Macro: INIT_SECTION_ASM_OP 19848 If defined, a C string constant, including spacing, for the 19849 assembler operation to identify the following data as 19850 initialization code. If not defined, GCC will assume such a 19851 section does not exist. When you are using special sections for 19852 initialization and termination functions, this macro also controls 19853 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization 19854 functions. 19855 19856 -- Macro: HAS_INIT_SECTION 19857 If defined, `main' will not call `__main' as described above. 19858 This macro should be defined for systems that control start-up code 19859 on a symbol-by-symbol basis, such as OSF/1, and should not be 19860 defined explicitly for systems that support `INIT_SECTION_ASM_OP'. 19861 19862 -- Macro: LD_INIT_SWITCH 19863 If defined, a C string constant for a switch that tells the linker 19864 that the following symbol is an initialization routine. 19865 19866 -- Macro: LD_FINI_SWITCH 19867 If defined, a C string constant for a switch that tells the linker 19868 that the following symbol is a finalization routine. 19869 19870 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 19871 If defined, a C statement that will write a function that can be 19872 automatically called when a shared library is loaded. The function 19873 should call FUNC, which takes no arguments. If not defined, and 19874 the object format requires an explicit initialization function, 19875 then a function called `_GLOBAL__DI' will be generated. 19876 19877 This function and the following one are used by collect2 when 19878 linking a shared library that needs constructors or destructors, 19879 or has DWARF2 exception tables embedded in the code. 19880 19881 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 19882 If defined, a C statement that will write a function that can be 19883 automatically called when a shared library is unloaded. The 19884 function should call FUNC, which takes no arguments. If not 19885 defined, and the object format requires an explicit finalization 19886 function, then a function called `_GLOBAL__DD' will be generated. 19887 19888 -- Macro: INVOKE__main 19889 If defined, `main' will call `__main' despite the presence of 19890 `INIT_SECTION_ASM_OP'. This macro should be defined for systems 19891 where the init section is not actually run automatically, but is 19892 still useful for collecting the lists of constructors and 19893 destructors. 19894 19895 -- Macro: SUPPORTS_INIT_PRIORITY 19896 If nonzero, the C++ `init_priority' attribute is supported and the 19897 compiler should emit instructions to control the order of 19898 initialization of objects. If zero, the compiler will issue an 19899 error message upon encountering an `init_priority' attribute. 19900 19901 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 19902 This value is true if the target supports some "native" method of 19903 collecting constructors and destructors to be run at startup and 19904 exit. It is false if we must use `collect2'. 19905 19906 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 19907 If defined, a function that outputs assembler code to arrange to 19908 call the function referenced by SYMBOL at initialization time. 19909 19910 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no 19911 arguments and with no return value. If the target supports 19912 initialization priorities, PRIORITY is a value between 0 and 19913 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'. 19914 19915 If this macro is not defined by the target, a suitable default will 19916 be chosen if (1) the target supports arbitrary section names, (2) 19917 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2' 19918 is not defined. 19919 19920 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 19921 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination 19922 functions rather than initialization functions. 19923 19924 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 19925generated for the generated object file will have static linkage. 19926 19927 If your system uses `collect2' as the means of processing 19928constructors, then that program normally uses `nm' to scan an object 19929file for constructor functions to be called. 19930 19931 On certain kinds of systems, you can define this macro to make 19932`collect2' work faster (and, in some cases, make it work at all): 19933 19934 -- Macro: OBJECT_FORMAT_COFF 19935 Define this macro if the system uses COFF (Common Object File 19936 Format) object files, so that `collect2' can assume this format 19937 and scan object files directly for dynamic constructor/destructor 19938 functions. 19939 19940 This macro is effective only in a native compiler; `collect2' as 19941 part of a cross compiler always uses `nm' for the target machine. 19942 19943 -- Macro: COLLECT_PARSE_FLAG (FLAG) 19944 Define this macro to be C code that examines `collect2' command 19945 line option FLAG and performs special actions if `collect2' needs 19946 to behave differently depending on FLAG. 19947 19948 -- Macro: REAL_NM_FILE_NAME 19949 Define this macro as a C string constant containing the file name 19950 to use to execute `nm'. The default is to search the path 19951 normally for `nm'. 19952 19953 If your system supports shared libraries and has a program to list 19954 the dynamic dependencies of a given library or executable, you can 19955 define these macros to enable support for running initialization 19956 and termination functions in shared libraries: 19957 19958 -- Macro: LDD_SUFFIX 19959 Define this macro to a C string constant containing the name of 19960 the program which lists dynamic dependencies, like `"ldd"' under 19961 SunOS 4. 19962 19963 -- Macro: PARSE_LDD_OUTPUT (PTR) 19964 Define this macro to be C code that extracts filenames from the 19965 output of the program denoted by `LDD_SUFFIX'. PTR is a variable 19966 of type `char *' that points to the beginning of a line of output 19967 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the 19968 code must advance PTR to the beginning of the filename on that 19969 line. Otherwise, it must set PTR to `NULL'. 19970 19971 19972File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 19973 1997411.20.7 Output of Assembler Instructions 19975---------------------------------------- 19976 19977This describes assembler instruction output. 19978 19979 -- Macro: REGISTER_NAMES 19980 A C initializer containing the assembler's names for the machine 19981 registers, each one as a C string constant. This is what 19982 translates register numbers in the compiler into assembler 19983 language. 19984 19985 -- Macro: ADDITIONAL_REGISTER_NAMES 19986 If defined, a C initializer for an array of structures containing 19987 a name and a register number. This macro defines additional names 19988 for hard registers, thus allowing the `asm' option in declarations 19989 to refer to registers using alternate names. 19990 19991 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 19992 Define this macro if you are using an unusual assembler that 19993 requires different names for the machine instructions. 19994 19995 The definition is a C statement or statements which output an 19996 assembler instruction opcode to the stdio stream STREAM. The 19997 macro-operand PTR is a variable of type `char *' which points to 19998 the opcode name in its "internal" form--the form that is written 19999 in the machine description. The definition should output the 20000 opcode name to STREAM, performing any translation you desire, and 20001 increment the variable PTR to point at the end of the opcode so 20002 that it will not be output twice. 20003 20004 In fact, your macro definition may process less than the entire 20005 opcode name, or more than the opcode name; but if you want to 20006 process text that includes `%'-sequences to substitute operands, 20007 you must take care of the substitution yourself. Just be sure to 20008 increment PTR over whatever text should not be output normally. 20009 20010 If you need to look at the operand values, they can be found as the 20011 elements of `recog_data.operand'. 20012 20013 If the macro definition does nothing, the instruction is output in 20014 the usual way. 20015 20016 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 20017 If defined, a C statement to be executed just prior to the output 20018 of assembler code for INSN, to modify the extracted operands so 20019 they will be output differently. 20020 20021 Here the argument OPVEC is the vector containing the operands 20022 extracted from INSN, and NOPERANDS is the number of elements of 20023 the vector which contain meaningful data for this insn. The 20024 contents of this vector are what will be used to convert the insn 20025 template into assembler code, so you can change the assembler 20026 output by changing the contents of the vector. 20027 20028 This macro is useful when various assembler syntaxes share a single 20029 file of instruction patterns; by defining this macro differently, 20030 you can cause a large class of instructions to be output 20031 differently (such as with rearranged operands). Naturally, 20032 variations in assembler syntax affecting individual insn patterns 20033 ought to be handled by writing conditional output routines in 20034 those patterns. 20035 20036 If this macro is not defined, it is equivalent to a null statement. 20037 20038 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 20039 A C compound statement to output to stdio stream STREAM the 20040 assembler syntax for an instruction operand X. X is an RTL 20041 expression. 20042 20043 CODE is a value that can be used to specify one of several ways of 20044 printing the operand. It is used when identical operands must be 20045 printed differently depending on the context. CODE comes from the 20046 `%' specification that was used to request printing of the 20047 operand. If the specification was just `%DIGIT' then CODE is 0; 20048 if the specification was `%LTR DIGIT' then CODE is the ASCII code 20049 for LTR. 20050 20051 If X is a register, this macro should print the register's name. 20052 The names can be found in an array `reg_names' whose type is `char 20053 *[]'. `reg_names' is initialized from `REGISTER_NAMES'. 20054 20055 When the machine description has a specification `%PUNCT' (a `%' 20056 followed by a punctuation character), this macro is called with a 20057 null pointer for X and the punctuation character for CODE. 20058 20059 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 20060 A C expression which evaluates to true if CODE is a valid 20061 punctuation character for use in the `PRINT_OPERAND' macro. If 20062 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 20063 punctuation characters (except for the standard one, `%') are used 20064 in this way. 20065 20066 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 20067 A C compound statement to output to stdio stream STREAM the 20068 assembler syntax for an instruction operand that is a memory 20069 reference whose address is X. X is an RTL expression. 20070 20071 On some machines, the syntax for a symbolic address depends on the 20072 section that the address refers to. On these machines, define the 20073 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the 20074 `symbol_ref', and then check for it here. *Note Assembler 20075 Format::. 20076 20077 -- Macro: DBR_OUTPUT_SEQEND (FILE) 20078 A C statement, to be executed after all slot-filler instructions 20079 have been output. If necessary, call `dbr_sequence_length' to 20080 determine the number of slots filled in a sequence (zero if not 20081 currently outputting a sequence), to decide how many no-ops to 20082 output, or whatever. 20083 20084 Don't define this macro if it has nothing to do, but it is helpful 20085 in reading assembly output if the extent of the delay sequence is 20086 made explicit (e.g. with white space). 20087 20088 Note that output routines for instructions with delay slots must be 20089prepared to deal with not being output as part of a sequence (i.e. when 20090the scheduling pass is not run, or when no slot fillers could be 20091found.) The variable `final_sequence' is null when not processing a 20092sequence, otherwise it contains the `sequence' rtx being output. 20093 20094 -- Macro: REGISTER_PREFIX 20095 -- Macro: LOCAL_LABEL_PREFIX 20096 -- Macro: USER_LABEL_PREFIX 20097 -- Macro: IMMEDIATE_PREFIX 20098 If defined, C string expressions to be used for the `%R', `%L', 20099 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These 20100 are useful when a single `md' file must support multiple assembler 20101 formats. In that case, the various `tm.h' files can define these 20102 macros differently. 20103 20104 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 20105 If defined this macro should expand to a series of `case' 20106 statements which will be parsed inside the `switch' statement of 20107 the `asm_fprintf' function. This allows targets to define extra 20108 printf formats which may useful when generating their assembler 20109 statements. Note that uppercase letters are reserved for future 20110 generic extensions to asm_fprintf, and so are not available to 20111 target specific code. The output file is given by the parameter 20112 FILE. The varargs input pointer is ARGPTR and the rest of the 20113 format string, starting the character after the one that is being 20114 switched upon, is pointed to by FORMAT. 20115 20116 -- Macro: ASSEMBLER_DIALECT 20117 If your target supports multiple dialects of assembler language 20118 (such as different opcodes), define this macro as a C expression 20119 that gives the numeric index of the assembler language dialect to 20120 use, with zero as the first variant. 20121 20122 If this macro is defined, you may use constructs of the form 20123 `{option0|option1|option2...}' 20124 in the output templates of patterns (*note Output Template::) or 20125 in the first argument of `asm_fprintf'. This construct outputs 20126 `option0', `option1', `option2', etc., if the value of 20127 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 20128 within these strings retain their usual meaning. If there are 20129 fewer alternatives within the braces than the value of 20130 `ASSEMBLER_DIALECT', the construct outputs nothing. 20131 20132 If you do not define this macro, the characters `{', `|' and `}' 20133 do not have any special meaning when used in templates or operands 20134 to `asm_fprintf'. 20135 20136 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', 20137 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the 20138 variations in assembler language syntax with that mechanism. 20139 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax 20140 if the syntax variant are larger and involve such things as 20141 different opcodes or operand order. 20142 20143 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 20144 A C expression to output to STREAM some assembler code which will 20145 push hard register number REGNO onto the stack. The code need not 20146 be optimal, since this macro is used only when profiling. 20147 20148 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 20149 A C expression to output to STREAM some assembler code which will 20150 pop hard register number REGNO off of the stack. The code need 20151 not be optimal, since this macro is used only when profiling. 20152 20153 20154File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 20155 2015611.20.8 Output of Dispatch Tables 20157--------------------------------- 20158 20159This concerns dispatch tables. 20160 20161 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 20162 A C statement to output to the stdio stream STREAM an assembler 20163 pseudo-instruction to generate a difference between two labels. 20164 VALUE and REL are the numbers of two internal labels. The 20165 definitions of these labels are output using 20166 `(*targetm.asm_out.internal_label)', and they must be printed in 20167 the same way here. For example, 20168 20169 fprintf (STREAM, "\t.word L%d-L%d\n", 20170 VALUE, REL) 20171 20172 You must provide this macro on machines where the addresses in a 20173 dispatch table are relative to the table's own address. If 20174 defined, GCC will also use this macro on all machines when 20175 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is 20176 provided so that the mode and flags can be read. 20177 20178 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 20179 This macro should be provided on machines where the addresses in a 20180 dispatch table are absolute. 20181 20182 The definition should be a C statement to output to the stdio 20183 stream STREAM an assembler pseudo-instruction to generate a 20184 reference to a label. VALUE is the number of an internal label 20185 whose definition is output using 20186 `(*targetm.asm_out.internal_label)'. For example, 20187 20188 fprintf (STREAM, "\t.word L%d\n", VALUE) 20189 20190 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 20191 Define this if the label before a jump-table needs to be output 20192 specially. The first three arguments are the same as for 20193 `(*targetm.asm_out.internal_label)'; the fourth argument is the 20194 jump-table which follows (a `jump_insn' containing an `addr_vec' 20195 or `addr_diff_vec'). 20196 20197 This feature is used on system V to output a `swbeg' statement for 20198 the table. 20199 20200 If this macro is not defined, these labels are output with 20201 `(*targetm.asm_out.internal_label)'. 20202 20203 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 20204 Define this if something special must be output at the end of a 20205 jump-table. The definition should be a C statement to be executed 20206 after the assembler code for the table is written. It should write 20207 the appropriate code to stdio stream STREAM. The argument TABLE 20208 is the jump-table insn, and NUM is the label-number of the 20209 preceding label. 20210 20211 If this macro is not defined, nothing special is output at the end 20212 of the jump-table. 20213 20214 20215File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 20216 2021711.20.9 Assembler Commands for Exception Regions 20218------------------------------------------------ 20219 20220This describes commands marking the start and the end of an exception 20221region. 20222 20223 -- Macro: EH_FRAME_SECTION_NAME 20224 If defined, a C string constant for the name of the section 20225 containing exception handling frame unwind information. If not 20226 defined, GCC will provide a default definition if the target 20227 supports named sections. `crtstuff.c' uses this macro to switch 20228 to the appropriate section. 20229 20230 You should define this symbol if your target supports DWARF 2 frame 20231 unwind information and the default definition does not work. 20232 20233 -- Macro: EH_FRAME_IN_DATA_SECTION 20234 If defined, DWARF 2 frame unwind information will be placed in the 20235 data section even though the target supports named sections. This 20236 might be necessary, for instance, if the system linker does garbage 20237 collection and sections cannot be marked as not to be collected. 20238 20239 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also 20240 defined. 20241 20242 -- Macro: MASK_RETURN_ADDR 20243 An rtx used to mask the return address found via 20244 `RETURN_ADDR_RTX', so that it does not contain any extraneous set 20245 bits in it. 20246 20247 -- Macro: DWARF2_UNWIND_INFO 20248 Define this macro to 0 if your target supports DWARF 2 frame unwind 20249 information, but it does not yet work with exception handling. 20250 Otherwise, if your target supports this information (if it defines 20251 `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or 20252 `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1. 20253 20254 If this macro is defined to 1, the DWARF 2 unwinder will be the 20255 default exception handling mechanism; otherwise, 20256 `setjmp'/`longjmp' will be used by default. 20257 20258 If this macro is defined to anything, the DWARF 2 unwinder will be 20259 used instead of inline unwinders and `__unwind_function' in the 20260 non-`setjmp' case. 20261 20262 -- Macro: MUST_USE_SJLJ_EXCEPTIONS 20263 This macro need only be defined if `DWARF2_UNWIND_INFO' is 20264 runtime-variable. In that case, `except.h' cannot correctly 20265 determine the corresponding definition of 20266 `MUST_USE_SJLJ_EXCEPTIONS', so the target must provide it directly. 20267 20268 -- Macro: DWARF_CIE_DATA_ALIGNMENT 20269 This macro need only be defined if the target might save registers 20270 in the function prologue at an offset to the stack pointer that is 20271 not aligned to `UNITS_PER_WORD'. The definition should be the 20272 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined, 20273 and the positive minimum alignment otherwise. *Note SDB and 20274 DWARF::. Only applicable if the target supports DWARF 2 frame 20275 unwind information. 20276 20277 -- Target Hook: void TARGET_ASM_EXCEPTION_SECTION () 20278 If defined, a function that switches to the section in which the 20279 main exception table is to be placed (*note Sections::). The 20280 default is a function that switches to a section named 20281 `.gcc_except_table' on machines that support named sections via 20282 `TARGET_ASM_NAMED_SECTION', otherwise if `-fpic' or `-fPIC' is in 20283 effect, the `data_section', otherwise the `readonly_data_section'. 20284 20285 -- Target Hook: void TARGET_ASM_EH_FRAME_SECTION () 20286 If defined, a function that switches to the section in which the 20287 DWARF 2 frame unwind information to be placed (*note Sections::). 20288 The default is a function that outputs a standard GAS section 20289 directive, if `EH_FRAME_SECTION_NAME' is defined, or else a data 20290 section directive followed by a synthetic label. 20291 20292 -- Variable: Target Hook bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 20293 Contains the value true if the target should add a zero word onto 20294 the end of a Dwarf-2 frame info section when used for exception 20295 handling. Default value is false if `EH_FRAME_SECTION_NAME' is 20296 defined, and true otherwise. 20297 20298 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 20299 Given a register, this hook should return a parallel of registers 20300 to represent where to find the register pieces. Define this hook 20301 if the register and its mode are represented in Dwarf in 20302 non-contiguous locations, or if the register should be represented 20303 in more than one register in Dwarf. Otherwise, this hook should 20304 return `NULL_RTX'. If not defined, the default is to return 20305 `NULL_RTX'. 20306 20307 20308File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 20309 2031011.20.10 Assembler Commands for Alignment 20311----------------------------------------- 20312 20313This describes commands for alignment. 20314 20315 -- Macro: JUMP_ALIGN (LABEL) 20316 The alignment (log base 2) to put in front of LABEL, which is a 20317 common destination of jumps and has no fallthru incoming edge. 20318 20319 This macro need not be defined if you don't want any special 20320 alignment to be done at such a time. Most machine descriptions do 20321 not currently define the macro. 20322 20323 Unless it's necessary to inspect the LABEL parameter, it is better 20324 to set the variable ALIGN_JUMPS in the target's 20325 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 20326 selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation. 20327 20328 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 20329 The alignment (log base 2) to put in front of LABEL, which follows 20330 a `BARRIER'. 20331 20332 This macro need not be defined if you don't want any special 20333 alignment to be done at such a time. Most machine descriptions do 20334 not currently define the macro. 20335 20336 -- Macro: LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 20337 The maximum number of bytes to skip when applying 20338 `LABEL_ALIGN_AFTER_BARRIER'. This works only if 20339 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 20340 20341 -- Macro: LOOP_ALIGN (LABEL) 20342 The alignment (log base 2) to put in front of LABEL, which follows 20343 a `NOTE_INSN_LOOP_BEG' note. 20344 20345 This macro need not be defined if you don't want any special 20346 alignment to be done at such a time. Most machine descriptions do 20347 not currently define the macro. 20348 20349 Unless it's necessary to inspect the LABEL parameter, it is better 20350 to set the variable `align_loops' in the target's 20351 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 20352 selection in `align_loops' in a `LOOP_ALIGN' implementation. 20353 20354 -- Macro: LOOP_ALIGN_MAX_SKIP 20355 The maximum number of bytes to skip when applying `LOOP_ALIGN'. 20356 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 20357 20358 -- Macro: LABEL_ALIGN (LABEL) 20359 The alignment (log base 2) to put in front of LABEL. If 20360 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different 20361 alignment, the maximum of the specified values is used. 20362 20363 Unless it's necessary to inspect the LABEL parameter, it is better 20364 to set the variable `align_labels' in the target's 20365 `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's 20366 selection in `align_labels' in a `LABEL_ALIGN' implementation. 20367 20368 -- Macro: LABEL_ALIGN_MAX_SKIP 20369 The maximum number of bytes to skip when applying `LABEL_ALIGN'. 20370 This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 20371 20372 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 20373 A C statement to output to the stdio stream STREAM an assembler 20374 instruction to advance the location counter by NBYTES bytes. 20375 Those bytes should be zero when loaded. NBYTES will be a C 20376 expression of type `int'. 20377 20378 -- Macro: ASM_NO_SKIP_IN_TEXT 20379 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the 20380 text section because it fails to put zeros in the bytes that are 20381 skipped. This is true on many Unix systems, where the pseudo-op 20382 to skip bytes produces no-op instructions rather than zeros when 20383 used in the text section. 20384 20385 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 20386 A C statement to output to the stdio stream STREAM an assembler 20387 command to advance the location counter to a multiple of 2 to the 20388 POWER bytes. POWER will be a C expression of type `int'. 20389 20390 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 20391 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 20392 for padding, if necessary. 20393 20394 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 20395 A C statement to output to the stdio stream STREAM an assembler 20396 command to advance the location counter to a multiple of 2 to the 20397 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 20398 satisfy the alignment request. POWER and MAX_SKIP will be a C 20399 expression of type `int'. 20400 20401 20402File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 20403 2040411.21 Controlling Debugging Information Format 20405============================================== 20406 20407This describes how to specify debugging information. 20408 20409* Menu: 20410 20411* All Debuggers:: Macros that affect all debugging formats uniformly. 20412* DBX Options:: Macros enabling specific options in DBX format. 20413* DBX Hooks:: Hook macros for varying DBX format. 20414* File Names and DBX:: Macros controlling output of file names in DBX format. 20415* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 20416* VMS Debug:: Macros for VMS debug format. 20417 20418 20419File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 20420 2042111.21.1 Macros Affecting All Debugging Formats 20422---------------------------------------------- 20423 20424These macros affect all debugging formats. 20425 20426 -- Macro: DBX_REGISTER_NUMBER (REGNO) 20427 A C expression that returns the DBX register number for the 20428 compiler register number REGNO. In the default macro provided, 20429 the value of this expression will be REGNO itself. But sometimes 20430 there are some registers that the compiler knows about and DBX 20431 does not, or vice versa. In such cases, some register may need to 20432 have one number in the compiler and another for DBX. 20433 20434 If two registers have consecutive numbers inside GCC, and they can 20435 be used as a pair to hold a multiword value, then they _must_ have 20436 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'. 20437 Otherwise, debuggers will be unable to access such a pair, because 20438 they expect register pairs to be consecutive in their own 20439 numbering scheme. 20440 20441 If you find yourself defining `DBX_REGISTER_NUMBER' in way that 20442 does not preserve register pairs, then what you must do instead is 20443 redefine the actual register numbering scheme. 20444 20445 -- Macro: DEBUGGER_AUTO_OFFSET (X) 20446 A C expression that returns the integer offset value for an 20447 automatic variable having address X (an RTL expression). The 20448 default computation assumes that X is based on the frame-pointer 20449 and gives the offset from the frame-pointer. This is required for 20450 targets that produce debugging output for DBX or COFF-style 20451 debugging output for SDB and allow the frame-pointer to be 20452 eliminated when the `-g' options is used. 20453 20454 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 20455 A C expression that returns the integer offset value for an 20456 argument having address X (an RTL expression). The nominal offset 20457 is OFFSET. 20458 20459 -- Macro: PREFERRED_DEBUGGING_TYPE 20460 A C expression that returns the type of debugging output GCC should 20461 produce when the user specifies just `-g'. Define this if you 20462 have arranged for GCC to support more than one format of debugging 20463 output. Currently, the allowable values are `DBX_DEBUG', 20464 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG', 20465 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'. 20466 20467 When the user specifies `-ggdb', GCC normally also uses the value 20468 of this macro to select the debugging output format, but with two 20469 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the 20470 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is 20471 defined, GCC uses `DBX_DEBUG'. 20472 20473 The value of this macro only affects the default debugging output; 20474 the user can always get a specific type of output by using 20475 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'. 20476 20477 20478File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 20479 2048011.21.2 Specific Options for DBX Output 20481--------------------------------------- 20482 20483These are specific options for DBX output. 20484 20485 -- Macro: DBX_DEBUGGING_INFO 20486 Define this macro if GCC should produce debugging output for DBX 20487 in response to the `-g' option. 20488 20489 -- Macro: XCOFF_DEBUGGING_INFO 20490 Define this macro if GCC should produce XCOFF format debugging 20491 output in response to the `-g' option. This is a variant of DBX 20492 format. 20493 20494 -- Macro: DEFAULT_GDB_EXTENSIONS 20495 Define this macro to control whether GCC should by default generate 20496 GDB's extended version of DBX debugging information (assuming 20497 DBX-format debugging information is enabled at all). If you don't 20498 define the macro, the default is 1: always generate the extended 20499 information if there is any occasion to. 20500 20501 -- Macro: DEBUG_SYMS_TEXT 20502 Define this macro if all `.stabs' commands should be output while 20503 in the text section. 20504 20505 -- Macro: ASM_STABS_OP 20506 A C string constant, including spacing, naming the assembler 20507 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary 20508 debugging symbol. If you don't define this macro, `"\t.stabs\t"' 20509 is used. This macro applies only to DBX debugging information 20510 format. 20511 20512 -- Macro: ASM_STABD_OP 20513 A C string constant, including spacing, naming the assembler 20514 pseudo op to use instead of `"\t.stabd\t"' to define a debugging 20515 symbol whose value is the current location. If you don't define 20516 this macro, `"\t.stabd\t"' is used. This macro applies only to 20517 DBX debugging information format. 20518 20519 -- Macro: ASM_STABN_OP 20520 A C string constant, including spacing, naming the assembler 20521 pseudo op to use instead of `"\t.stabn\t"' to define a debugging 20522 symbol with no name. If you don't define this macro, 20523 `"\t.stabn\t"' is used. This macro applies only to DBX debugging 20524 information format. 20525 20526 -- Macro: DBX_NO_XREFS 20527 Define this macro if DBX on your system does not support the 20528 construct `xsTAGNAME'. On some systems, this construct is used to 20529 describe a forward reference to a structure named TAGNAME. On 20530 other systems, this construct is not supported at all. 20531 20532 -- Macro: DBX_CONTIN_LENGTH 20533 A symbol name in DBX-format debugging information is normally 20534 continued (split into two separate `.stabs' directives) when it 20535 exceeds a certain length (by default, 80 characters). On some 20536 operating systems, DBX requires this splitting; on others, 20537 splitting must not be done. You can inhibit splitting by defining 20538 this macro with the value zero. You can override the default 20539 splitting-length by defining this macro as an expression for the 20540 length you desire. 20541 20542 -- Macro: DBX_CONTIN_CHAR 20543 Normally continuation is indicated by adding a `\' character to 20544 the end of a `.stabs' string when a continuation follows. To use 20545 a different character instead, define this macro as a character 20546 constant for the character you want to use. Do not define this 20547 macro if backslash is correct for your system. 20548 20549 -- Macro: DBX_STATIC_STAB_DATA_SECTION 20550 Define this macro if it is necessary to go to the data section 20551 before outputting the `.stabs' pseudo-op for a non-global static 20552 variable. 20553 20554 -- Macro: DBX_TYPE_DECL_STABS_CODE 20555 The value to use in the "code" field of the `.stabs' directive for 20556 a typedef. The default is `N_LSYM'. 20557 20558 -- Macro: DBX_STATIC_CONST_VAR_CODE 20559 The value to use in the "code" field of the `.stabs' directive for 20560 a static variable located in the text section. DBX format does not 20561 provide any "right" way to do this. The default is `N_FUN'. 20562 20563 -- Macro: DBX_REGPARM_STABS_CODE 20564 The value to use in the "code" field of the `.stabs' directive for 20565 a parameter passed in registers. DBX format does not provide any 20566 "right" way to do this. The default is `N_RSYM'. 20567 20568 -- Macro: DBX_REGPARM_STABS_LETTER 20569 The letter to use in DBX symbol data to identify a symbol as a 20570 parameter passed in registers. DBX format does not customarily 20571 provide any way to do this. The default is `'P''. 20572 20573 -- Macro: DBX_MEMPARM_STABS_LETTER 20574 The letter to use in DBX symbol data to identify a symbol as a 20575 stack parameter. The default is `'p''. 20576 20577 -- Macro: DBX_FUNCTION_FIRST 20578 Define this macro if the DBX information for a function and its 20579 arguments should precede the assembler code for the function. 20580 Normally, in DBX format, the debugging information entirely 20581 follows the assembler code. 20582 20583 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 20584 Define this macro if the value of a symbol describing the scope of 20585 a block (`N_LBRAC' or `N_RBRAC') should be relative to the start 20586 of the enclosing function. Normally, GCC uses an absolute address. 20587 20588 -- Macro: DBX_USE_BINCL 20589 Define this macro if GCC should generate `N_BINCL' and `N_EINCL' 20590 stabs for included header files, as on Sun systems. This macro 20591 also directs GCC to output a type number as a pair of a file 20592 number and a type number within the file. Normally, GCC does not 20593 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single 20594 number for a type number. 20595 20596 20597File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 20598 2059911.21.3 Open-Ended Hooks for DBX Format 20600--------------------------------------- 20601 20602These are hooks for DBX format. 20603 20604 -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME) 20605 Define this macro to say how to output to STREAM the debugging 20606 information for the start of a scope level for variable names. The 20607 argument NAME is the name of an assembler symbol (for use with 20608 `assemble_name') whose value is the address where the scope begins. 20609 20610 -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME) 20611 Like `DBX_OUTPUT_LBRAC', but for the end of a scope level. 20612 20613 -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL) 20614 Define this macro if the target machine requires special handling 20615 to output an `N_FUN' entry for the function DECL. 20616 20617 -- Macro: DBX_OUTPUT_FUNCTION_END (STREAM, FUNCTION) 20618 Define this macro if the target machine requires special output at 20619 the end of the debugging information for a function. The 20620 definition should be a C statement (sans semicolon) to output the 20621 appropriate information to STREAM. FUNCTION is the 20622 `FUNCTION_DECL' node for the function. 20623 20624 -- Macro: DBX_OUTPUT_STANDARD_TYPES (SYMS) 20625 Define this macro if you need to control the order of output of the 20626 standard data types at the beginning of compilation. The argument 20627 SYMS is a `tree' which is a chain of all the predefined global 20628 symbols, including names of data types. 20629 20630 Normally, DBX output starts with definitions of the types for 20631 integers and characters, followed by all the other predefined 20632 types of the particular language in no particular order. 20633 20634 On some machines, it is necessary to output different particular 20635 types first. To do this, define `DBX_OUTPUT_STANDARD_TYPES' to 20636 output those symbols in the necessary order. Any predefined types 20637 that you don't explicitly output will be output afterward in no 20638 particular order. 20639 20640 Be careful not to define this macro so that it works only for C. 20641 There are no global variables to access most of the built-in 20642 types, because another language may have another set of types. 20643 The way to output a particular type is to look through SYMS to see 20644 if you can find it. Here is an example: 20645 20646 { 20647 tree decl; 20648 for (decl = syms; decl; decl = TREE_CHAIN (decl)) 20649 if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)), 20650 "long int")) 20651 dbxout_symbol (decl); 20652 ... 20653 } 20654 20655 This does nothing if the expected type does not exist. 20656 20657 See the function `init_decl_processing' in `c-decl.c' to find the 20658 names to use for all the built-in C types. 20659 20660 Here is another way of finding a particular type: 20661 20662 { 20663 tree decl; 20664 for (decl = syms; decl; decl = TREE_CHAIN (decl)) 20665 if (TREE_CODE (decl) == TYPE_DECL 20666 && (TREE_CODE (TREE_TYPE (decl)) 20667 == INTEGER_CST) 20668 && TYPE_PRECISION (TREE_TYPE (decl)) == 16 20669 && TYPE_UNSIGNED (TREE_TYPE (decl))) 20670 /* This must be `unsigned short'. */ 20671 dbxout_symbol (decl); 20672 ... 20673 } 20674 20675 -- Macro: NO_DBX_FUNCTION_END 20676 Some stabs encapsulation formats (in particular ECOFF), cannot 20677 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 20678 extension construct. On those machines, define this macro to turn 20679 this feature off without disturbing the rest of the gdb extensions. 20680 20681 20682File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 20683 2068411.21.4 File Names in DBX Format 20685-------------------------------- 20686 20687This describes file names in DBX format. 20688 20689 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 20690 A C statement to output DBX debugging information to the stdio 20691 stream STREAM which indicates that file NAME is the main source 20692 file--the file specified as the input file for compilation. This 20693 macro is called only once, at the beginning of compilation. 20694 20695 This macro need not be defined if the standard form of output for 20696 DBX debugging information is appropriate. 20697 20698 -- Macro: DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (STREAM, NAME) 20699 A C statement to output DBX debugging information to the stdio 20700 stream STREAM which indicates that the current directory during 20701 compilation is named NAME. 20702 20703 This macro need not be defined if the standard form of output for 20704 DBX debugging information is appropriate. 20705 20706 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 20707 A C statement to output DBX debugging information at the end of 20708 compilation of the main source file NAME. 20709 20710 If you don't define this macro, nothing special is output at the 20711 end of compilation, which is correct for most machines. 20712 20713 20714File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 20715 2071611.21.5 Macros for SDB and DWARF Output 20717--------------------------------------- 20718 20719Here are macros for SDB and DWARF output. 20720 20721 -- Macro: SDB_DEBUGGING_INFO 20722 Define this macro if GCC should produce COFF-style debugging output 20723 for SDB in response to the `-g' option. 20724 20725 -- Macro: DWARF2_DEBUGGING_INFO 20726 Define this macro if GCC should produce dwarf version 2 format 20727 debugging output in response to the `-g' option. 20728 20729 To support optional call frame debugging information, you must also 20730 define `INCOMING_RETURN_ADDR_RTX' and either set 20731 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 20732 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as 20733 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 20734 20735 -- Macro: DWARF2_FRAME_INFO 20736 Define this macro to a nonzero value if GCC should always output 20737 Dwarf 2 frame information. If `DWARF2_UNWIND_INFO' (*note 20738 Exception Region Output:: is nonzero, GCC will output this 20739 information not matter how you define `DWARF2_FRAME_INFO'. 20740 20741 -- Macro: DWARF2_GENERATE_TEXT_SECTION_LABEL 20742 By default, the Dwarf 2 debugging information generator will 20743 generate a label to mark the beginning of the text section. If it 20744 is better simply to use the name of the text section itself, 20745 rather than an explicit label, to indicate the beginning of the 20746 text section, define this macro to zero. 20747 20748 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 20749 Define this macro to be a nonzero value if the assembler can 20750 generate Dwarf 2 line debug info sections. This will result in 20751 much more compact line number tables, and hence is desirable if it 20752 works. 20753 20754 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 20755 A C statement to issue assembly directives that create a difference 20756 between the two given labels, using an integer of the given size. 20757 20758 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL) 20759 A C statement to issue assembly directives that create a 20760 section-relative reference to the given label, using an integer of 20761 the given size. 20762 20763 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 20764 A C statement to issue assembly directives that create a 20765 self-relative reference to the given label, using an integer of 20766 the given size. 20767 20768 -- Macro: PUT_SDB_... 20769 Define these macros to override the assembler syntax for the 20770 special SDB assembler directives. See `sdbout.c' for a list of 20771 these macros and their arguments. If the standard syntax is used, 20772 you need not define them yourself. 20773 20774 -- Macro: SDB_DELIM 20775 Some assemblers do not support a semicolon as a delimiter, even 20776 between SDB assembler directives. In that case, define this macro 20777 to be the delimiter to use (usually `\n'). It is not necessary to 20778 define a new set of `PUT_SDB_OP' macros if this is the only change 20779 required. 20780 20781 -- Macro: SDB_GENERATE_FAKE 20782 Define this macro to override the usual method of constructing a 20783 dummy name for anonymous structure and union types. See 20784 `sdbout.c' for more information. 20785 20786 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 20787 Define this macro to allow references to unknown structure, union, 20788 or enumeration tags to be emitted. Standard COFF does not allow 20789 handling of unknown references, MIPS ECOFF has support for it. 20790 20791 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 20792 Define this macro to allow references to structure, union, or 20793 enumeration tags that have not yet been seen to be handled. Some 20794 assemblers choke if forward tags are used, while some require it. 20795 20796 20797File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 20798 2079911.21.6 Macros for VMS Debug Format 20800----------------------------------- 20801 20802Here are macros for VMS debug format. 20803 20804 -- Macro: VMS_DEBUGGING_INFO 20805 Define this macro if GCC should produce debugging output for VMS 20806 in response to the `-g' option. The default behavior for VMS is 20807 to generate minimal debug info for a traceback in the absence of 20808 `-g' unless explicitly overridden with `-g0'. This behavior is 20809 controlled by `OPTIMIZATION_OPTIONS' and `OVERRIDE_OPTIONS'. 20810 20811 20812File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 20813 2081411.22 Cross Compilation and Floating Point 20815========================================== 20816 20817While all modern machines use twos-complement representation for 20818integers, there are a variety of representations for floating point 20819numbers. This means that in a cross-compiler the representation of 20820floating point numbers in the compiled program may be different from 20821that used in the machine doing the compilation. 20822 20823 Because different representation systems may offer different amounts 20824of range and precision, all floating point constants must be 20825represented in the target machine's format. Therefore, the cross 20826compiler cannot safely use the host machine's floating point 20827arithmetic; it must emulate the target's arithmetic. To ensure 20828consistency, GCC always uses emulation to work with floating point 20829values, even when the host and target floating point formats are 20830identical. 20831 20832 The following macros are provided by `real.h' for the compiler to 20833use. All parts of the compiler which generate or optimize 20834floating-point calculations must use these macros. They may evaluate 20835their operands more than once, so operands must not have side effects. 20836 20837 -- Macro: REAL_VALUE_TYPE 20838 The C data type to be used to hold a floating point value in the 20839 target machine's format. Typically this is a `struct' containing 20840 an array of `HOST_WIDE_INT', but all code should treat it as an 20841 opaque quantity. 20842 20843 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 20844 Compares for equality the two values, X and Y. If the target 20845 floating point format supports negative zeroes and/or NaNs, 20846 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL 20847 (NaN, NaN)' is false. 20848 20849 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 20850 Tests whether X is less than Y. 20851 20852 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 20853 Truncates X to a signed integer, rounding toward zero. 20854 20855 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 20856 (REAL_VALUE_TYPE X) 20857 Truncates X to an unsigned integer, rounding toward zero. If X is 20858 negative, returns zero. 20859 20860 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum 20861 machine_mode MODE) 20862 Converts STRING into a floating point number in the target 20863 machine's representation for mode MODE. This routine can handle 20864 both decimal and hexadecimal floating point constants, using the 20865 syntax defined by the C language for both. 20866 20867 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 20868 Returns 1 if X is negative (including negative zero), 0 otherwise. 20869 20870 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 20871 Determines whether X represents infinity (positive or negative). 20872 20873 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 20874 Determines whether X represents a "NaN" (not-a-number). 20875 20876 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 20877 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 20878 Calculates an arithmetic operation on the two floating point values 20879 X and Y, storing the result in OUTPUT (which must be a variable). 20880 20881 The operation to be performed is specified by CODE. Only the 20882 following codes are supported: `PLUS_EXPR', `MINUS_EXPR', 20883 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. 20884 20885 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the 20886 target's floating point format cannot represent infinity, it will 20887 call `abort'. Callers should check for this situation first, using 20888 `MODE_HAS_INFINITIES'. *Note Storage Layout::. 20889 20890 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 20891 Returns the negative of the floating point value X. 20892 20893 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 20894 Returns the absolute value of X. 20895 20896 -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE, 20897 enum machine_mode X) 20898 Truncates the floating point value X to fit in MODE. The return 20899 value is still a full-size `REAL_VALUE_TYPE', but it has an 20900 appropriate bit pattern to be output asa floating constant whose 20901 precision accords with mode MODE. 20902 20903 -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT 20904 HIGH, REAL_VALUE_TYPE X) 20905 Converts a floating point value X into a double-precision integer 20906 which is then stored into LOW and HIGH. If the value is not 20907 integral, it is truncated. 20908 20909 -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT 20910 LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE) 20911 Converts a double-precision integer found in LOW and HIGH, into a 20912 floating point value which is then stored into X. The value is 20913 truncated to fit in mode MODE. 20914 20915 20916File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 20917 2091811.23 Mode Switching Instructions 20919================================= 20920 20921The following macros control mode switching optimizations: 20922 20923 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 20924 Define this macro if the port needs extra instructions inserted 20925 for mode switching in an optimizing compilation. 20926 20927 For an example, the SH4 can perform both single and double 20928 precision floating point operations, but to perform a single 20929 precision operation, the FPSCR PR bit has to be cleared, while for 20930 a double precision operation, this bit has to be set. Changing 20931 the PR bit requires a general purpose register as a scratch 20932 register, hence these FPSCR sets have to be inserted before 20933 reload, i.e. you can't put this into instruction emitting or 20934 `TARGET_MACHINE_DEPENDENT_REORG'. 20935 20936 You can have multiple entities that are mode-switched, and select 20937 at run time which entities actually need it. 20938 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY 20939 that needs mode-switching. If you define this macro, you also 20940 have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', 20941 `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER', 20942 `MODE_ENTRY', and `MODE_EXIT' are optional. 20943 20944 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 20945 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as 20946 initializer for an array of integers. Each initializer element N 20947 refers to an entity that needs mode switching, and specifies the 20948 number of different modes that might need to be set for this 20949 entity. The position of the initializer in the initializer - 20950 starting counting at zero - determines the integer that is used to 20951 refer to the mode-switched entity in question. In macros that 20952 take mode arguments / yield a mode result, modes are represented 20953 as numbers 0 ... N - 1. N is used to specify that no mode switch 20954 is needed / supplied. 20955 20956 -- Macro: MODE_NEEDED (ENTITY, INSN) 20957 ENTITY is an integer specifying a mode-switched entity. If 20958 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 20959 return an integer value not larger than the corresponding element 20960 in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 20961 must be switched into prior to the execution of INSN. 20962 20963 -- Macro: MODE_AFTER (MODE, INSN) 20964 If this macro is defined, it is evaluated for every INSN during 20965 mode switching. It determines the mode that an insn results in (if 20966 different from the incoming mode). 20967 20968 -- Macro: MODE_ENTRY (ENTITY) 20969 If this macro is defined, it is evaluated for every ENTITY that 20970 needs mode switching. It should evaluate to an integer, which is a 20971 mode that ENTITY is assumed to be switched to at function entry. 20972 If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined. 20973 20974 -- Macro: MODE_EXIT (ENTITY) 20975 If this macro is defined, it is evaluated for every ENTITY that 20976 needs mode switching. It should evaluate to an integer, which is a 20977 mode that ENTITY is assumed to be switched to at function exit. If 20978 `MODE_EXIT' is defined then `MODE_ENTRY' must be defined. 20979 20980 -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N) 20981 This macro specifies the order in which modes for ENTITY are 20982 processed. 0 is the highest priority, 20983 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 20984 of the macro should be an integer designating a mode for ENTITY. 20985 For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be 20986 a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'. 20987 20988 -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE) 20989 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE 20990 is the set of hard registers live at the point where the insn(s) 20991 are to be inserted. 20992 20993 20994File: gccint.info, Node: Target Attributes, Next: MIPS Coprocessors, Prev: Mode Switching, Up: Target Macros 20995 2099611.24 Defining target-specific uses of `__attribute__' 20997====================================================== 20998 20999Target-specific attributes may be defined for functions, data and types. 21000These are described using the following target hooks; they also need to 21001be documented in `extend.texi'. 21002 21003 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 21004 If defined, this target hook points to an array of `struct 21005 attribute_spec' (defined in `tree.h') specifying the machine 21006 specific attributes for this target and some of the restrictions 21007 on the entities to which these attributes are applied and the 21008 arguments they take. 21009 21010 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, tree 21011 TYPE2) 21012 If defined, this target hook is a function which returns zero if 21013 the attributes on TYPE1 and TYPE2 are incompatible, one if they 21014 are compatible, and two if they are nearly compatible (which 21015 causes a warning to be generated). If this is not defined, 21016 machine-specific attributes are supposed always to be compatible. 21017 21018 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 21019 If defined, this target hook is a function which assigns default 21020 attributes to newly defined TYPE. 21021 21022 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 21023 TYPE2) 21024 Define this target hook if the merging of type attributes needs 21025 special handling. If defined, the result is a list of the combined 21026 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 21027 `comptypes' has already been called and returned 1. This function 21028 may call `merge_attributes' to handle machine-independent merging. 21029 21030 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 21031 NEWDECL) 21032 Define this target hook if the merging of decl attributes needs 21033 special handling. If defined, the result is a list of the combined 21034 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 21035 declaration of OLDDECL. Examples of when this is needed are when 21036 one attribute overrides another, or when an attribute is nullified 21037 by a subsequent definition. This function may call 21038 `merge_attributes' to handle machine-independent merging. 21039 21040 If the only target-specific handling you require is `dllimport' for 21041 Microsoft Windows targets, you should define the macro 21042 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. This links in a function 21043 called `merge_dllimport_decl_attributes' which can then be defined 21044 as the expansion of `TARGET_MERGE_DECL_ATTRIBUTES'. This is done 21045 in `i386/cygwin.h' and `i386/i386.c', for example. 21046 21047 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 21048 *ATTR_PTR) 21049 Define this target hook if you want to be able to add attributes 21050 to a decl when it is being created. This is normally useful for 21051 back ends which wish to implement a pragma by using the attributes 21052 which correspond to the pragma's effect. The NODE argument is the 21053 decl which is being created. The ATTR_PTR argument is a pointer 21054 to the attribute list for this decl. The list itself should not 21055 be modified, since it may be shared with other decls, but 21056 attributes may be chained on the head of the list and `*ATTR_PTR' 21057 modified to point to the new attributes, or a copy of the list may 21058 be made if further changes are needed. 21059 21060 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (tree 21061 FNDECL) 21062 This target hook returns `true' if it is ok to inline FNDECL into 21063 the current function, despite its having target-specific 21064 attributes, `false' otherwise. By default, if a function has a 21065 target specific attribute attached to it, it will not be inlined. 21066 21067 21068File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Target Attributes, Up: Target Macros 21069 2107011.25 Defining coprocessor specifics for MIPS targets. 21071====================================================== 21072 21073The MIPS specification allows MIPS implementations to have as many as 4 21074coprocessors, each with as many as 32 private registers. GCC supports 21075accessing these registers and transferring values between the registers 21076and memory using asm-ized variables. For example: 21077 21078 register unsigned int cp0count asm ("c0r1"); 21079 unsigned int d; 21080 21081 d = cp0count + 3; 21082 21083 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 21084names may be added as described below, or the default names may be 21085overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 21086 21087 Coprocessor registers are assumed to be epilogue-used; sets to them 21088will be preserved even if it does not appear that the register is used 21089again later in the function. 21090 21091 Another note: according to the MIPS spec, coprocessor 1 (if present) 21092is the FPU. One accesses COP1 registers through standard mips 21093floating-point support; they are not included in this mechanism. 21094 21095 There is one macro used in defining the MIPS coprocessor interface 21096which you may want to override in subtargets; it is described below. 21097 21098 -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES 21099 A comma-separated list (with leading comma) of pairs describing the 21100 alternate names of coprocessor registers. The format of each 21101 entry should be 21102 { ALTERNATENAME, REGISTER_NUMBER} 21103 Default: empty. 21104 21105 21106File: gccint.info, Node: PCH Target, Next: Misc, Prev: MIPS Coprocessors, Up: Target Macros 21107 2110811.26 Parameters for Precompiled Header Validity Checking 21109========================================================= 21110 21111 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t * SZ) 21112 Define this hook if your target needs to check a different 21113 collection of flags than the default, which is every flag defined 21114 by `TARGET_SWITCHES' and `TARGET_OPTIONS'. It should return some 21115 data which will be saved in the PCH file and presented to 21116 `TARGET_PCH_VALID_P' later; it should set `SZ' to the size of the 21117 data. 21118 21119 -- Target Hook: const char * TARGET_PCH_VALID_P (const void * DATA, 21120 size_t SZ) 21121 Define this hook if your target needs to check a different 21122 collection of flags than the default, which is every flag defined 21123 by `TARGET_SWITCHES' and `TARGET_OPTIONS'. It is given data which 21124 came from `TARGET_GET_PCH_VALIDITY' (in this version of this 21125 compiler, so there is no need for extensive validity checking). 21126 It returns `NULL' if it is safe to load a PCH file with this data, 21127 or a suitable error message if not. The error message will be 21128 presented to the user, so it should be localized. 21129 21130 21131File: gccint.info, Node: Misc, Prev: PCH Target, Up: Target Macros 21132 2113311.27 Miscellaneous Parameters 21134============================== 21135 21136Here are several miscellaneous parameters. 21137 21138 -- Macro: PREDICATE_CODES 21139 Define this if you have defined special-purpose predicates in the 21140 file `MACHINE.c'. This macro is called within an initializer of an 21141 array of structures. The first field in the structure is the name 21142 of a predicate and the second field is an array of rtl codes. For 21143 each predicate, list all rtl codes that can be in expressions 21144 matched by the predicate. The list should have a trailing comma. 21145 Here is an example of two entries in the list for a typical RISC 21146 machine: 21147 21148 #define PREDICATE_CODES \ 21149 {"gen_reg_rtx_operand", {SUBREG, REG}}, \ 21150 {"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}}, 21151 21152 Defining this macro does not affect the generated code (however, 21153 incorrect definitions that omit an rtl code that may be matched by 21154 the predicate can cause the compiler to malfunction). Instead, it 21155 allows the table built by `genrecog' to be more compact and 21156 efficient, thus speeding up the compiler. The most important 21157 predicates to include in the list specified by this macro are 21158 those used in the most insn patterns. 21159 21160 For each predicate function named in `PREDICATE_CODES', a 21161 declaration will be generated in `insn-codes.h'. 21162 21163 -- Macro: SPECIAL_MODE_PREDICATES 21164 Define this if you have special predicates that know special things 21165 about modes. Genrecog will warn about certain forms of 21166 `match_operand' without a mode; if the operand predicate is listed 21167 in `SPECIAL_MODE_PREDICATES', the warning will be suppressed. 21168 21169 Here is an example from the IA-32 port (`ext_register_operand' 21170 specially checks for `HImode' or `SImode' in preparation for a 21171 byte extraction from `%ah' etc.). 21172 21173 #define SPECIAL_MODE_PREDICATES \ 21174 "ext_register_operand", 21175 21176 -- Macro: CASE_VECTOR_MODE 21177 An alias for a machine mode name. This is the machine mode that 21178 elements of a jump-table should have. 21179 21180 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 21181 Optional: return the preferred mode for an `addr_diff_vec' when 21182 the minimum and maximum offset are known. If you define this, it 21183 enables extra code in branch shortening to deal with 21184 `addr_diff_vec'. To make this work, you also have to define 21185 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit. 21186 The BODY argument is provided so that the offset_unsigned and scale 21187 flags can be updated. 21188 21189 -- Macro: CASE_VECTOR_PC_RELATIVE 21190 Define this macro to be a C expression to indicate when jump-tables 21191 should contain relative addresses. You need not define this macro 21192 if jump-tables never contain relative addresses, or jump-tables 21193 should contain relative addresses only when `-fPIC' or `-fPIC' is 21194 in effect. 21195 21196 -- Macro: CASE_DROPS_THROUGH 21197 Define this if control falls through a `case' insn when the index 21198 value is out of range. This means the specified default-label is 21199 actually ignored by the `case' insn proper. 21200 21201 -- Macro: CASE_VALUES_THRESHOLD 21202 Define this to be the smallest number of different values for 21203 which it is best to use a jump-table instead of a tree of 21204 conditional branches. The default is four for machines with a 21205 `casesi' instruction and five otherwise. This is best for most 21206 machines. 21207 21208 -- Macro: CASE_USE_BIT_TESTS 21209 Define this macro to be a C expression to indicate whether C switch 21210 statements may be implemented by a sequence of bit tests. This is 21211 advantageous on processors that can efficiently implement left 21212 shift of 1 by the number of bits held in a register, but 21213 inappropriate on targets that would require a loop. By default, 21214 this macro returns `true' if the target defines an `ashlsi3' 21215 pattern, and `false' otherwise. 21216 21217 -- Macro: WORD_REGISTER_OPERATIONS 21218 Define this macro if operations between registers with integral 21219 mode smaller than a word are always performed on the entire 21220 register. Most RISC machines have this property and most CISC 21221 machines do not. 21222 21223 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 21224 Define this macro to be a C expression indicating when insns that 21225 read memory in MEM_MODE, an integral mode narrower than a word, 21226 set the bits outside of MEM_MODE to be either the sign-extension 21227 or the zero-extension of the data read. Return `SIGN_EXTEND' for 21228 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND' 21229 for which it zero-extends, and `NIL' for other modes. 21230 21231 This macro is not called with MEM_MODE non-integral or with a width 21232 greater than or equal to `BITS_PER_WORD', so you may return any 21233 value in this case. Do not define this macro if it would always 21234 return `NIL'. On machines where this macro is defined, you will 21235 normally define it as the constant `SIGN_EXTEND' or `ZERO_EXTEND'. 21236 21237 You may return a non-`NIL' value even if for some hard registers 21238 the sign extension is not performed, if for the `REGNO_REG_CLASS' 21239 of these hard registers `CANNOT_CHANGE_MODE_CLASS' returns nonzero 21240 when the FROM mode is MEM_MODE and the TO mode is any integral 21241 mode larger than this but not larger than `word_mode'. 21242 21243 You must return `NIL' if for some hard registers that allow this 21244 mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change to 21245 `word_mode', but that they can change to another integral mode that 21246 is larger then MEM_MODE but still smaller than `word_mode'. 21247 21248 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 21249 Define this macro if loading short immediate values into registers 21250 sign extends. 21251 21252 -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC 21253 Define this macro if the same instructions that convert a floating 21254 point number to a signed fixed point number also convert validly 21255 to an unsigned one. 21256 21257 -- Macro: MOVE_MAX 21258 The maximum number of bytes that a single instruction can move 21259 quickly between memory and registers or between two memory 21260 locations. 21261 21262 -- Macro: MAX_MOVE_MAX 21263 The maximum number of bytes that a single instruction can move 21264 quickly between memory and registers or between two memory 21265 locations. If this is undefined, the default is `MOVE_MAX'. 21266 Otherwise, it is the constant value that is the largest value that 21267 `MOVE_MAX' can have at run-time. 21268 21269 -- Macro: SHIFT_COUNT_TRUNCATED 21270 A C expression that is nonzero if on this machine the number of 21271 bits actually used for the count of a shift operation is equal to 21272 the number of bits needed to represent the size of the object 21273 being shifted. When this macro is nonzero, the compiler will 21274 assume that it is safe to omit a sign-extend, zero-extend, and 21275 certain bitwise `and' instructions that truncates the count of a 21276 shift operation. On machines that have instructions that act on 21277 bit-fields at variable positions, which may include `bit test' 21278 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables 21279 deletion of truncations of the values that serve as arguments to 21280 bit-field instructions. 21281 21282 If both types of instructions truncate the count (for shifts) and 21283 position (for bit-field operations), or if no variable-position 21284 bit-field instructions exist, you should define this macro. 21285 21286 However, on some machines, such as the 80386 and the 680x0, 21287 truncation only applies to shift operations and not the (real or 21288 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' 21289 to be zero on such machines. Instead, add patterns to the `md' 21290 file that include the implied truncation of the shift instructions. 21291 21292 You need not define this macro if it would always have the value 21293 of zero. 21294 21295 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 21296 A C expression which is nonzero if on this machine it is safe to 21297 "convert" an integer of INPREC bits to one of OUTPREC bits (where 21298 OUTPREC is smaller than INPREC) by merely operating on it as if it 21299 had only OUTPREC bits. 21300 21301 On many machines, this expression can be 1. 21302 21303 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 21304 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 21305 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in 21306 such cases may improve things. 21307 21308 -- Macro: STORE_FLAG_VALUE 21309 A C expression describing the value returned by a comparison 21310 operator with an integral mode and stored by a store-flag 21311 instruction (`sCOND') when the condition is true. This 21312 description must apply to _all_ the `sCOND' patterns and all the 21313 comparison operators whose results have a `MODE_INT' mode. 21314 21315 A value of 1 or -1 means that the instruction implementing the 21316 comparison operator returns exactly 1 or -1 when the comparison is 21317 true and 0 when the comparison is false. Otherwise, the value 21318 indicates which bits of the result are guaranteed to be 1 when the 21319 comparison is true. This value is interpreted in the mode of the 21320 comparison operation, which is given by the mode of the first 21321 operand in the `sCOND' pattern. Either the low bit or the sign 21322 bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are 21323 used by the compiler. 21324 21325 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 21326 generate code that depends only on the specified bits. It can also 21327 replace comparison operators with equivalent operations if they 21328 cause the required bits to be set, even if the remaining bits are 21329 undefined. For example, on a machine whose comparison operators 21330 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as 21331 `0x80000000', saying that just the sign bit is relevant, the 21332 expression 21333 21334 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 21335 21336 can be converted to 21337 21338 (ashift:SI X (const_int N)) 21339 21340 where N is the appropriate shift count to move the bit being 21341 tested into the sign bit. 21342 21343 There is no way to describe a machine that always sets the 21344 low-order bit for a true value, but does not guarantee the value 21345 of any other bits, but we do not know of any machine that has such 21346 an instruction. If you are trying to port GCC to such a machine, 21347 include an instruction to perform a logical-and of the result with 21348 1 in the pattern for the comparison operators and let us know at 21349 <gcc@gcc.gnu.org>. 21350 21351 Often, a machine will have multiple instructions that obtain a 21352 value from a comparison (or the condition codes). Here are rules 21353 to guide the choice of value for `STORE_FLAG_VALUE', and hence the 21354 instructions to be used: 21355 21356 * Use the shortest sequence that yields a valid definition for 21357 `STORE_FLAG_VALUE'. It is more efficient for the compiler to 21358 "normalize" the value (convert it to, e.g., 1 or 0) than for 21359 the comparison operators to do so because there may be 21360 opportunities to combine the normalization with other 21361 operations. 21362 21363 * For equal-length sequences, use a value of 1 or -1, with -1 21364 being slightly preferred on machines with expensive jumps and 21365 1 preferred on other machines. 21366 21367 * As a second choice, choose a value of `0x80000001' if 21368 instructions exist that set both the sign and low-order bits 21369 but do not define the others. 21370 21371 * Otherwise, use a value of `0x80000000'. 21372 21373 Many machines can produce both the value chosen for 21374 `STORE_FLAG_VALUE' and its negation in the same number of 21375 instructions. On those machines, you should also define a pattern 21376 for those cases, e.g., one matching 21377 21378 (set A (neg:M (ne:M B C))) 21379 21380 Some machines can also perform `and' or `plus' operations on 21381 condition code values with less instructions than the corresponding 21382 `sCOND' insn followed by `and' or `plus'. On those machines, 21383 define the appropriate patterns. Use the names `incscc' and 21384 `decscc', respectively, for the patterns which perform `plus' or 21385 `minus' operations on condition code values. See `rs6000.md' for 21386 some examples. The GNU Superoptizer can be used to find such 21387 instruction sequences on other machines. 21388 21389 If this macro is not defined, the default value, 1, is used. You 21390 need not define `STORE_FLAG_VALUE' if the machine has no store-flag 21391 instructions, or if the value generated by these instructions is 1. 21392 21393 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 21394 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is 21395 returned when comparison operators with floating-point results are 21396 true. Define this macro on machine that have comparison 21397 operations that return floating-point values. If there are no 21398 such operations, do not define this macro. 21399 21400 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 21401 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 21402 A C expression that evaluates to true if the architecture defines 21403 a value for `clz' or `ctz' with a zero operand. If so, VALUE 21404 should be set to this value. If this macro is not defined, the 21405 value of `clz' or `ctz' is assumed to be undefined. 21406 21407 This macro must be defined if the target's expansion for `ffs' 21408 relies on a particular value to get correct results. Otherwise it 21409 is not necessary, though it may be used to optimize some corner 21410 cases. 21411 21412 Note that regardless of this macro the "definedness" of `clz' and 21413 `ctz' at zero do _not_ extend to the builtin functions visible to 21414 the user. Thus one may be free to adjust the value at will to 21415 match the target expansion of these operations without fear of 21416 breaking the API. 21417 21418 -- Macro: Pmode 21419 An alias for the machine mode for pointers. On most machines, 21420 define this to be the integer mode corresponding to the width of a 21421 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit 21422 machines. On some machines you must define this to be one of the 21423 partial integer modes, such as `PSImode'. 21424 21425 The width of `Pmode' must be at least as large as the value of 21426 `POINTER_SIZE'. If it is not equal, you must define the macro 21427 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 21428 `Pmode'. 21429 21430 -- Macro: FUNCTION_MODE 21431 An alias for the machine mode used for memory references to 21432 functions being called, in `call' RTL expressions. On most 21433 machines this should be `QImode'. 21434 21435 -- Macro: INTEGRATE_THRESHOLD (DECL) 21436 A C expression for the maximum number of instructions above which 21437 the function DECL should not be inlined. DECL is a 21438 `FUNCTION_DECL' node. 21439 21440 The default definition of this macro is 64 plus 8 times the number 21441 of arguments that the function accepts. Some people think a larger 21442 threshold should be used on RISC machines. 21443 21444 -- Macro: STDC_0_IN_SYSTEM_HEADERS 21445 In normal operation, the preprocessor expands `__STDC__' to the 21446 constant 1, to signify that GCC conforms to ISO Standard C. On 21447 some hosts, like Solaris, the system compiler uses a different 21448 convention, where `__STDC__' is normally 0, but is 1 if the user 21449 specifies strict conformance to the C Standard. 21450 21451 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 21452 convention when processing system header files, but when 21453 processing user files `__STDC__' will always expand to 1. 21454 21455 -- Macro: NO_IMPLICIT_EXTERN_C 21456 Define this macro if the system header files support C++ as well 21457 as C. This macro inhibits the usual method of using system header 21458 files in C++, which is to pretend that the file's contents are 21459 enclosed in `extern "C" {...}'. 21460 21461 -- Macro: REGISTER_TARGET_PRAGMAS () 21462 Define this macro if you want to implement any target-specific 21463 pragmas. If defined, it is a C expression which makes a series of 21464 calls to `c_register_pragma' for each pragma. The macro may also 21465 do any setup required for the pragmas. 21466 21467 The primary reason to define this macro is to provide 21468 compatibility with other compilers for the same target. In 21469 general, we discourage definition of target-specific pragmas for 21470 GCC. 21471 21472 If the pragma can be implemented by attributes then you should 21473 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as 21474 well. 21475 21476 Preprocessor macros that appear on pragma lines are not expanded. 21477 All `#pragma' directives that do not match any registered pragma 21478 are silently ignored, unless the user specifies 21479 `-Wunknown-pragmas'. 21480 21481 -- Function: void c_register_pragma (const char *SPACE, const char 21482 *NAME, void (*CALLBACK) (struct cpp_reader *)) 21483 Each call to `c_register_pragma' establishes one pragma. The 21484 CALLBACK routine will be called when the preprocessor encounters a 21485 pragma of the form 21486 21487 #pragma [SPACE] NAME ... 21488 21489 SPACE is the case-sensitive namespace of the pragma, or `NULL' to 21490 put the pragma in the global namespace. The callback routine 21491 receives PFILE as its first argument, which can be passed on to 21492 cpplib's functions if necessary. You can lex tokens after the 21493 NAME by calling `c_lex'. Tokens that are not read by the callback 21494 will be silently ignored. The end of the line is indicated by a 21495 token of type `CPP_EOF' 21496 21497 For an example use of this routine, see `c4x.h' and the callback 21498 routines defined in `c4x-c.c'. 21499 21500 Note that the use of `c_lex' is specific to the C and C++ 21501 compilers. It will not work in the Java or Fortran compilers, or 21502 any other language compilers for that matter. Thus if `c_lex' is 21503 going to be called from target-specific code, it must only be done 21504 so when building the C and C++ compilers. This can be done by 21505 defining the variables `c_target_objs' and `cxx_target_objs' in the 21506 target entry in the `config.gcc' file. These variables should name 21507 the target-specific, language-specific object file which contains 21508 the code that uses `c_lex'. Note it will also be necessary to add 21509 a rule to the makefile fragment pointed to by `tmake_file' that 21510 shows how to build this object file. 21511 21512 -- Macro: HANDLE_SYSV_PRAGMA 21513 Define this macro (to a value of 1) if you want the System V style 21514 pragmas `#pragma pack(<n>)' and `#pragma weak <name> [=<value>]' 21515 to be supported by gcc. 21516 21517 The pack pragma specifies the maximum alignment (in bytes) of 21518 fields within a structure, in much the same way as the 21519 `__aligned__' and `__packed__' `__attribute__'s do. A pack value 21520 of zero resets the behavior to the default. 21521 21522 A subtlety for Microsoft Visual C/C++ style bit-field packing 21523 (e.g. -mms-bitfields) for targets that support it: When a 21524 bit-field is inserted into a packed record, the whole size of the 21525 underlying type is used by one or more same-size adjacent 21526 bit-fields (that is, if its long:3, 32 bits is used in the record, 21527 and any additional adjacent long bit-fields are packed into the 21528 same chunk of 32 bits. However, if the size changes, a new field 21529 of that size is allocated). 21530 21531 If both MS bit-fields and `__attribute__((packed))' are used, the 21532 latter will take precedence. If `__attribute__((packed))' is used 21533 on a single field when MS bit-fields are in use, it will take 21534 precedence for that field, but the alignment of the rest of the 21535 structure may affect its placement. 21536 21537 The weak pragma only works if `SUPPORTS_WEAK' and 21538 `ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation 21539 of specifically named weak labels, optionally with a value. 21540 21541 -- Macro: HANDLE_PRAGMA_PACK_PUSH_POP 21542 Define this macro (to a value of 1) if you want to support the 21543 Win32 style pragmas `#pragma pack(push,N)' and `#pragma 21544 pack(pop)'. The `pack(push,N)' pragma specifies the maximum 21545 alignment (in bytes) of fields within a structure, in much the 21546 same way as the `__aligned__' and `__packed__' `__attribute__'s 21547 do. A pack value of zero resets the behavior to the default. 21548 Successive invocations of this pragma cause the previous values to 21549 be stacked, so that invocations of `#pragma pack(pop)' will return 21550 to the previous value. 21551 21552 -- Macro: DOLLARS_IN_IDENTIFIERS 21553 Define this macro to control use of the character `$' in 21554 identifier names for the C family of languages. 0 means `$' is 21555 not allowed by default; 1 means it is allowed. 1 is the default; 21556 there is no need to define this macro in that case. 21557 21558 -- Macro: NO_DOLLAR_IN_LABEL 21559 Define this macro if the assembler does not accept the character 21560 `$' in label names. By default constructors and destructors in 21561 G++ have `$' in the identifiers. If this macro is defined, `.' is 21562 used instead. 21563 21564 -- Macro: NO_DOT_IN_LABEL 21565 Define this macro if the assembler does not accept the character 21566 `.' in label names. By default constructors and destructors in G++ 21567 have names that use `.'. If this macro is defined, these names 21568 are rewritten to avoid `.'. 21569 21570 -- Macro: DEFAULT_MAIN_RETURN 21571 Define this macro if the target system expects every program's 21572 `main' function to return a standard "success" value by default 21573 (if no other value is explicitly returned). 21574 21575 The definition should be a C statement (sans semicolon) to 21576 generate the appropriate rtl instructions. It is used only when 21577 compiling the end of `main'. 21578 21579 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 21580 Define this macro as a C expression that is nonzero if it is safe 21581 for the delay slot scheduler to place instructions in the delay 21582 slot of INSN, even if they appear to use a resource set or 21583 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC 21584 knows that every `call_insn' has this behavior. On machines where 21585 some `insn' or `jump_insn' is really a function call and hence has 21586 this behavior, you should define this macro. 21587 21588 You need not define this macro if it would always return zero. 21589 21590 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 21591 Define this macro as a C expression that is nonzero if it is safe 21592 for the delay slot scheduler to place instructions in the delay 21593 slot of INSN, even if they appear to set or clobber a resource 21594 referenced in INSN. INSN is always a `jump_insn' or an `insn'. 21595 On machines where some `insn' or `jump_insn' is really a function 21596 call and its operands are registers whose use is actually in the 21597 subroutine it calls, you should define this macro. Doing so 21598 allows the delay slot scheduler to move instructions which copy 21599 arguments into the argument registers into the delay slot of INSN. 21600 21601 You need not define this macro if it would always return zero. 21602 21603 -- Macro: MULTIPLE_SYMBOL_SPACES 21604 Define this macro if in some cases global symbols from one 21605 translation unit may not be bound to undefined symbols in another 21606 translation unit without user intervention. For instance, under 21607 Microsoft Windows symbols must be explicitly imported from shared 21608 libraries (DLLs). 21609 21610 -- Macro: MD_ASM_CLOBBERS (CLOBBERS) 21611 A C statement that adds to CLOBBERS `STRING_CST' trees for any 21612 hard regs the port wishes to automatically clobber for all asms. 21613 21614 -- Macro: MATH_LIBRARY 21615 Define this macro as a C string constant for the linker argument 21616 to link in the system math library, or `""' if the target does not 21617 have a separate math library. 21618 21619 You need only define this macro if the default of `"-lm"' is wrong. 21620 21621 -- Macro: LIBRARY_PATH_ENV 21622 Define this macro as a C string constant for the environment 21623 variable that specifies where the linker should look for libraries. 21624 21625 You need only define this macro if the default of `"LIBRARY_PATH"' 21626 is wrong. 21627 21628 -- Macro: TARGET_HAS_F_SETLKW 21629 Define this macro if the target supports file locking with fcntl / 21630 F_SETLKW. Note that this functionality is part of POSIX. 21631 Defining `TARGET_HAS_F_SETLKW' will enable the test coverage code 21632 to use file locking when exiting a program, which avoids race 21633 conditions if the program has forked. 21634 21635 -- Macro: MAX_CONDITIONAL_EXECUTE 21636 A C expression for the maximum number of instructions to execute 21637 via conditional execution instructions instead of a branch. A 21638 value of `BRANCH_COST'+1 is the default if the machine does not 21639 use cc0, and 1 if it does use cc0. 21640 21641 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 21642 Used if the target needs to perform machine-dependent 21643 modifications on the conditionals used for turning basic blocks 21644 into conditionally executed code. CE_INFO points to a data 21645 structure, `struct ce_if_block', which contains information about 21646 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the 21647 tests that are used for converting the then-block and the 21648 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a 21649 null pointer if the tests cannot be converted. 21650 21651 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 21652 FALSE_EXPR) 21653 Like `IFCVT_MODIFY_TESTS', but used when converting more 21654 complicated if-statements into conditions combined by `and' and 21655 `or' operations. BB contains the basic block that contains the 21656 test that is currently being processed and about to be turned into 21657 a condition. 21658 21659 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 21660 A C expression to modify the PATTERN of an INSN that is to be 21661 converted to conditional execution format. CE_INFO points to a 21662 data structure, `struct ce_if_block', which contains information 21663 about the currently processed blocks. 21664 21665 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 21666 A C expression to perform any final machine dependent 21667 modifications in converting code to conditional execution. The 21668 involved basic blocks can be found in the `struct ce_if_block' 21669 structure that is pointed to by CE_INFO. 21670 21671 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 21672 A C expression to cancel any machine dependent modifications in 21673 converting code to conditional execution. The involved basic 21674 blocks can be found in the `struct ce_if_block' structure that is 21675 pointed to by CE_INFO. 21676 21677 -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO) 21678 A C expression to initialize any extra fields in a `struct 21679 ce_if_block' structure, which are defined by the 21680 `IFCVT_EXTRA_FIELDS' macro. 21681 21682 -- Macro: IFCVT_EXTRA_FIELDS 21683 If defined, it should expand to a set of field declarations that 21684 will be added to the `struct ce_if_block' structure. These should 21685 be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro. 21686 21687 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG () 21688 If non-null, this hook performs a target-specific pass over the 21689 instruction stream. The compiler will run it at all optimization 21690 levels, just before the point at which it normally does 21691 delayed-branch scheduling. 21692 21693 The exact purpose of the hook varies from target to target. Some 21694 use it to do transformations that are necessary for correctness, 21695 such as laying out in-function constant pools or avoiding hardware 21696 hazards. Others use it as an opportunity to do some 21697 machine-dependent optimizations. 21698 21699 You need not implement the hook if it has nothing to do. The 21700 default definition is null. 21701 21702 -- Target Hook: void TARGET_INIT_BUILTINS () 21703 Define this hook if you have any machine-specific built-in 21704 functions that need to be defined. It should be a function that 21705 performs the necessary setup. 21706 21707 Machine specific built-in functions can be useful to expand 21708 special machine instructions that would otherwise not normally be 21709 generated because they have no equivalent in the source language 21710 (for example, SIMD vector instructions or prefetch instructions). 21711 21712 To create a built-in function, call the function `builtin_function' 21713 which is defined by the language front end. You can use any type 21714 nodes set up by `build_common_tree_nodes' and 21715 `build_common_tree_nodes_2'; only language front ends that use 21716 those two functions will call `TARGET_INIT_BUILTINS'. 21717 21718 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 21719 SUBTARGET, enum machine_mode MODE, int IGNORE) 21720 Expand a call to a machine specific built-in function that was set 21721 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the 21722 function call; the result should go to TARGET if that is 21723 convenient, and have mode MODE if that is convenient. SUBTARGET 21724 may be used as the target for computing one of EXP's operands. 21725 IGNORE is nonzero if the value is to be ignored. This function 21726 should return the result of the call to the built-in function. 21727 21728 -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2) 21729 Take a branch insn in BRANCH1 and another in BRANCH2. Return true 21730 if redirecting BRANCH1 to the destination of BRANCH2 is possible. 21731 21732 On some targets, branches may have a limited range. Optimizing the 21733 filling of delay slots can result in branches being redirected, 21734 and this may in turn cause a branch offset to overflow. 21735 21736 -- Macro: ALLOCATE_INITIAL_VALUE (HARD_REG) 21737 When the initial value of a hard register has been copied in a 21738 pseudo register, it is often not necessary to actually allocate 21739 another register to this pseudo register, because the original 21740 hard register or a stack slot it has been saved into can be used. 21741 `ALLOCATE_INITIAL_VALUE', if defined, is called at the start of 21742 register allocation once for each hard register that had its 21743 initial value copied by using `get_func_hard_reg_initial_val' or 21744 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if 21745 you don't want to do any special allocation, a `REG' rtx--that 21746 would typically be the hard register itself, if it is known not to 21747 be clobbered--or a `MEM'. If you are returning a `MEM', this is 21748 only a hint for the allocator; it might decide to use another 21749 register anyways. You may use `current_function_leaf_function' in 21750 the definition of the macro, functions that use `REG_N_SETS', to 21751 determine if the hard register in question will not be clobbered. 21752 21753 -- Macro: TARGET_OBJECT_SUFFIX 21754 Define this macro to be a C string representing the suffix for 21755 object files on your target machine. If you do not define this 21756 macro, GCC will use `.o' as the suffix for object files. 21757 21758 -- Macro: TARGET_EXECUTABLE_SUFFIX 21759 Define this macro to be a C string representing the suffix to be 21760 automatically added to executable files on your target machine. 21761 If you do not define this macro, GCC will use the null string as 21762 the suffix for executable files. 21763 21764 -- Macro: COLLECT_EXPORT_LIST 21765 If defined, `collect2' will scan the individual object files 21766 specified on its command line and create an export list for the 21767 linker. Define this macro for systems like AIX, where the linker 21768 discards object files that are not referenced from `main' and uses 21769 export lists. 21770 21771 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 21772 Define this macro to a C expression representing a variant of the 21773 method call MDECL, if Java Native Interface (JNI) methods must be 21774 invoked differently from other methods on your target. For 21775 example, on 32-bit Microsoft Windows, JNI methods must be invoked 21776 using the `stdcall' calling convention and this macro is then 21777 defined as this expression: 21778 21779 build_type_attribute_variant (MDECL, 21780 build_tree_list 21781 (get_identifier ("stdcall"), 21782 NULL)) 21783 21784 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 21785 This target hook returns `true' past the point in which new jump 21786 instructions could be created. On machines that require a 21787 register for every jump such as the SHmedia ISA of SH5, this point 21788 would typically be reload, so this target hook should be defined 21789 to a function such as: 21790 21791 static bool 21792 cannot_modify_jumps_past_reload_p () 21793 { 21794 return (reload_completed || reload_in_progress); 21795 } 21796 21797 -- Target Hook: int TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 21798 This target hook returns a register class for which branch target 21799 register optimizations should be applied. All registers in this 21800 class should be usable interchangeably. After reload, registers 21801 in this class will be re-allocated and loads will be hoisted out 21802 of loops and be subjected to inter-block scheduling. 21803 21804 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 21805 AFTER_PROLOGUE_EPILOGUE_GEN) 21806 Branch target register optimization will by default exclude 21807 callee-saved registers that are not already live during the 21808 current function; if this target hook returns true, they will be 21809 included. The target code must than make sure that all target 21810 registers in the class returned by 21811 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are 21812 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and 21813 epilogues have already been generated. Note, even if you only 21814 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still 21815 are likely to have to make special provisions in 21816 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 21817 target registers. 21818 21819 -- Macro: POWI_MAX_MULTS 21820 If defined, this macro is interpreted as a signed integer C 21821 expression that specifies the maximum number of floating point 21822 multiplications that should be emitted when expanding 21823 exponentiation by an integer constant inline. When this value is 21824 defined, exponentiation requiring more than this number of 21825 multiplications is implemented by calling the system library's 21826 `pow', `powf' or `powl' routines. The default value places no 21827 upper bound on the multiplication count. 21828 21829 21830File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 21831 2183212 Host Configuration 21833********************* 21834 21835Most details about the machine and system on which the compiler is 21836actually running are detected by the `configure' script. Some things 21837are impossible for `configure' to detect; these are described in two 21838ways, either by macros defined in a file named `xm-MACHINE.h' or by 21839hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable 21840in `config.gcc'. (The intention is that very few hosts will need a 21841header file but nearly every fully supported host will need to override 21842some hooks.) 21843 21844 If you need to define only a few macros, and they have simple 21845definitions, consider using the `xm_defines' variable in your 21846`config.gcc' entry instead of creating a host configuration header. 21847*Note System Config::. 21848 21849* Menu: 21850 21851* Host Common:: Things every host probably needs implemented. 21852* Filesystem:: Your host can't have the letter `a' in filenames? 21853* Host Misc:: Rare configuration options for hosts. 21854 21855 21856File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 21857 2185812.1 Host Common 21859================ 21860 21861Some things are just not portable, even between similar operating 21862systems, and are too difficult for autoconf to detect. They get 21863implemented using hook functions in the file specified by the 21864HOST_HOOK_OBJ variable in `config.gcc'. 21865 21866 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 21867 This host hook is used to set up handling for extra signals. The 21868 most common thing to do in this hook is to detect stack overflow. 21869 21870 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE) 21871 This host hook returns the address of some space in which a PCH 21872 may be loaded with `HOST_HOOKS_PCH_LOAD_PCH'. The space will need 21873 to have SIZE bytes. If insufficient space is available, `NULL' 21874 may be returned; the PCH machinery will try to find a suitable 21875 address using a heuristic. 21876 21877 The memory does not have to be available now. In fact, usually 21878 `HOST_HOOKS_PCH_LOAD_PCH' will already have been called. The 21879 memory need only be available in future invocations of GCC. 21880 21881 -- Host Hook: bool HOST_HOOKS_GT_PCH_USE_ADDRESS (size_t SIZE, void * 21882 ADDRESS) 21883 This host hook is called when a PCH file is about to be loaded. If 21884 ADDRESS is the address that would have been returned by 21885 `HOST_HOOKS_PCH_MEMORY_ADDRESS', and SIZE is smaller than the 21886 maximum than `HOST_HOOKS_PCH_MEMORY_ADDRESS' would have accepted, 21887 return true, otherwise return false. 21888 21889 In addition, free any address space reserved that isn't needed to 21890 hold SIZE bytes (whether or not true is returned). The PCH 21891 machinery will use `mmap' with `MAP_FIXED' to load the PCH if 21892 `HAVE_MMAP_FILE', or will use `fread' otherwise. 21893 21894 If no PCH will be loaded, this hook may be called with SIZE zero, 21895 in which case all reserved address space should be freed. 21896 21897 Do not try to handle values of ADDRESS that could not have been 21898 returned by this executable; just return false. Such values 21899 usually indicate an out-of-date PCH file (built by some other GCC 21900 executable), and such a PCH file won't work. 21901 21902 21903File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 21904 2190512.2 Host Filesystem 21906==================== 21907 21908GCC needs to know a number of things about the semantics of the host 21909machine's filesystem. Filesystems with Unix and MS-DOS semantics are 21910automatically detected. For other systems, you can define the 21911following macros in `xm-MACHINE.h'. 21912 21913`HAVE_DOS_BASED_FILE_SYSTEM' 21914 This macro is automatically defined by `system.h' if the host file 21915 system obeys the semantics defined by MS-DOS instead of Unix. DOS 21916 file systems are case insensitive, file specifications may begin 21917 with a drive letter, and both forward slash and backslash (`/' and 21918 `\') are directory separators. 21919 21920`DIR_SEPARATOR' 21921`DIR_SEPARATOR_2' 21922 If defined, these macros expand to character constants specifying 21923 separators for directory names within a file specification. 21924 `system.h' will automatically give them appropriate values on Unix 21925 and MS-DOS file systems. If your file system is neither of these, 21926 define one or both appropriately in `xm-MACHINE.h'. 21927 21928 However, operating systems like VMS, where constructing a pathname 21929 is more complicated than just stringing together directory names 21930 separated by a special character, should not define either of these 21931 macros. 21932 21933`PATH_SEPARATOR' 21934 If defined, this macro should expand to a character constant 21935 specifying the separator for elements of search paths. The default 21936 value is a colon (`:'). DOS-based systems usually, but not 21937 always, use semicolon (`;'). 21938 21939`VMS' 21940 Define this macro if the host system is VMS. 21941 21942`HOST_OBJECT_SUFFIX' 21943 Define this macro to be a C string representing the suffix for 21944 object files on your host machine. If you do not define this 21945 macro, GCC will use `.o' as the suffix for object files. 21946 21947`HOST_EXECUTABLE_SUFFIX' 21948 Define this macro to be a C string representing the suffix for 21949 executable files on your host machine. If you do not define this 21950 macro, GCC will use the null string as the suffix for executable 21951 files. 21952 21953`HOST_BIT_BUCKET' 21954 A pathname defined by the host operating system, which can be 21955 opened as a file and written to, but all the information written 21956 is discarded. This is commonly known as a "bit bucket" or "null 21957 device". If you do not define this macro, GCC will use 21958 `/dev/null' as the bit bucket. If the host does not support a bit 21959 bucket, define this macro to an invalid filename. 21960 21961`UPDATE_PATH_HOST_CANONICALIZE (PATH)' 21962 If defined, a C statement (sans semicolon) that performs 21963 host-dependent canonicalization when a path used in a compilation 21964 driver or preprocessor is canonicalized. PATH is a malloc-ed path 21965 to be canonicalized. If the C statement does canonicalize PATH 21966 into a different buffer, the old path should be freed and the new 21967 buffer should have been allocated with malloc. 21968 21969`DUMPFILE_FORMAT' 21970 Define this macro to be a C string representing the format to use 21971 for constructing the index part of debugging dump file names. The 21972 resultant string must fit in fifteen bytes. The full filename 21973 will be the concatenation of: the prefix of the assembler file 21974 name, the string resulting from applying this format to an index 21975 number, and a string unique to each dump file kind, e.g. `rtl'. 21976 21977 If you do not define this macro, GCC will use `.%02d.'. You should 21978 define this macro if using the default will create an invalid file 21979 name. 21980 21981 21982File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 21983 2198412.3 Host Misc 21985============== 21986 21987`FATAL_EXIT_CODE' 21988 A C expression for the status code to be returned when the compiler 21989 exits after serious errors. The default is the system-provided 21990 macro `EXIT_FAILURE', or `1' if the system doesn't define that 21991 macro. Define this macro only if these defaults are incorrect. 21992 21993`SUCCESS_EXIT_CODE' 21994 A C expression for the status code to be returned when the compiler 21995 exits without serious errors. (Warnings are not serious errors.) 21996 The default is the system-provided macro `EXIT_SUCCESS', or `0' if 21997 the system doesn't define that macro. Define this macro only if 21998 these defaults are incorrect. 21999 22000`USE_C_ALLOCA' 22001 Define this macro if GCC should use the C implementation of 22002 `alloca' provided by `libiberty.a'. This only affects how some 22003 parts of the compiler itself allocate memory. It does not change 22004 code generation. 22005 22006 When GCC is built with a compiler other than itself, the C `alloca' 22007 is always used. This is because most other implementations have 22008 serious bugs. You should define this macro only on a system where 22009 no stack-based `alloca' can possibly work. For instance, if a 22010 system has a small limit on the size of the stack, GCC's builtin 22011 `alloca' will not work reliably. 22012 22013`COLLECT2_HOST_INITIALIZATION' 22014 If defined, a C statement (sans semicolon) that performs 22015 host-dependent initialization when `collect2' is being initialized. 22016 22017`GCC_DRIVER_HOST_INITIALIZATION' 22018 If defined, a C statement (sans semicolon) that performs 22019 host-dependent initialization when a compilation driver is being 22020 initialized. 22021 22022`SMALL_ARG_MAX' 22023 Define this macro if the host system has a small limit on the total 22024 size of an argument vector. This causes the driver to take more 22025 care not to pass unnecessary arguments to subprocesses. 22026 22027 In addition, if `configure' generates an incorrect definition of any 22028of the macros in `auto-host.h', you can override that definition in a 22029host configuration header. If you need to do this, first see if it is 22030possible to fix `configure'. 22031 22032 22033File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 22034 2203513 Makefile Fragments 22036********************* 22037 22038When you configure GCC using the `configure' script, it will construct 22039the file `Makefile' from the template file `Makefile.in'. When it does 22040this, it can incorporate makefile fragments from the `config' 22041directory. These are used to set Makefile parameters that are not 22042amenable to being calculated by autoconf. The list of fragments to 22043incorporate is set by `config.gcc' (and occasionally `config.build' and 22044`config.host'); *Note System Config::. 22045 22046 Fragments are named either `t-TARGET' or `x-HOST', depending on 22047whether they are relevant to configuring GCC to produce code for a 22048particular target, or to configuring GCC to run on a particular host. 22049Here TARGET and HOST are mnemonics which usually have some relationship 22050to the canonical system name, but no formal connection. 22051 22052 If these files do not exist, it means nothing needs to be added for a 22053given target or host. Most targets need a few `t-TARGET' fragments, 22054but needing `x-HOST' fragments is rare. 22055 22056* Menu: 22057 22058* Target Fragment:: Writing `t-TARGET' files. 22059* Host Fragment:: Writing `x-HOST' files. 22060 22061 22062File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 22063 2206413.1 Target Makefile Fragments 22065============================== 22066 22067Target makefile fragments can set these Makefile variables. 22068 22069`LIBGCC2_CFLAGS' 22070 Compiler flags to use when compiling `libgcc2.c'. 22071 22072`LIB2FUNCS_EXTRA' 22073 A list of source file names to be compiled or assembled and 22074 inserted into `libgcc.a'. 22075 22076`Floating Point Emulation' 22077 To have GCC include software floating point libraries in `libgcc.a' 22078 define `FPBIT' and `DPBIT' along with a few rules as follows: 22079 # We want fine grained libraries, so use the new code 22080 # to build the floating point emulation libraries. 22081 FPBIT = fp-bit.c 22082 DPBIT = dp-bit.c 22083 22084 22085 fp-bit.c: $(srcdir)/config/fp-bit.c 22086 echo '#define FLOAT' > fp-bit.c 22087 cat $(srcdir)/config/fp-bit.c >> fp-bit.c 22088 22089 dp-bit.c: $(srcdir)/config/fp-bit.c 22090 cat $(srcdir)/config/fp-bit.c > dp-bit.c 22091 22092 You may need to provide additional #defines at the beginning of 22093 `fp-bit.c' and `dp-bit.c' to control target endianness and other 22094 options. 22095 22096`CRTSTUFF_T_CFLAGS' 22097 Special flags used when compiling `crtstuff.c'. *Note 22098 Initialization::. 22099 22100`CRTSTUFF_T_CFLAGS_S' 22101 Special flags used when compiling `crtstuff.c' for shared linking. 22102 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. 22103 *Note Initialization::. 22104 22105`MULTILIB_OPTIONS' 22106 For some targets, invoking GCC in different ways produces objects 22107 that can not be linked together. For example, for some targets GCC 22108 produces both big and little endian code. For these targets, you 22109 must arrange for multiple versions of `libgcc.a' to be compiled, 22110 one for each set of incompatible options. When GCC invokes the 22111 linker, it arranges to link in the right version of `libgcc.a', 22112 based on the command line options used. 22113 22114 The `MULTILIB_OPTIONS' macro lists the set of options for which 22115 special versions of `libgcc.a' must be built. Write options that 22116 are mutually incompatible side by side, separated by a slash. 22117 Write options that may be used together separated by a space. The 22118 build procedure will build all combinations of compatible options. 22119 22120 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 22121 msoft-float', `Makefile' will build special versions of `libgcc.a' 22122 using the following sets of options: `-m68000', `-m68020', 22123 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. 22124 22125`MULTILIB_DIRNAMES' 22126 If `MULTILIB_OPTIONS' is used, this variable specifies the 22127 directory names that should be used to hold the various libraries. 22128 Write one element in `MULTILIB_DIRNAMES' for each element in 22129 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the 22130 default value will be `MULTILIB_OPTIONS', with all slashes treated 22131 as spaces. 22132 22133 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 22134 msoft-float', then the default value of `MULTILIB_DIRNAMES' is 22135 `m68000 m68020 msoft-float'. You may specify a different value if 22136 you desire a different set of directory names. 22137 22138`MULTILIB_MATCHES' 22139 Sometimes the same option may be written in two different ways. 22140 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know 22141 about any synonyms. In that case, set `MULTILIB_MATCHES' to a 22142 list of items of the form `option=option' to describe all relevant 22143 synonyms. For example, `m68000=mc68000 m68020=mc68020'. 22144 22145`MULTILIB_EXCEPTIONS' 22146 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being 22147 specified, there are combinations that should not be built. In 22148 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch 22149 exceptions in shell case syntax that should not be built. 22150 22151 For example the ARM processor cannot execute both hardware floating 22152 point instructions and the reduced size THUMB instructions at the 22153 same time, so there is no need to build libraries with both of 22154 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: 22155 *mthumb/*mhard-float* 22156 22157`MULTILIB_EXTRA_OPTS' 22158 Sometimes it is desirable that when building multiple versions of 22159 `libgcc.a' certain options should always be passed on to the 22160 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list 22161 of options to be used for all builds. If you set this, you should 22162 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. 22163 22164`SPECS' 22165 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since 22166 it does not affect the build of target libraries, at least not the 22167 build of the default multilib. One possible work-around is to use 22168 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if 22169 they had been passed in the compiler driver command line. 22170 However, you don't want to be adding these options after the 22171 toolchain is installed, so you can instead tweak the `specs' file 22172 that will be used during the toolchain build, while you still 22173 install the original, built-in `specs'. The trick is to set 22174 `SPECS' to some other filename (say `specs.install'), that will 22175 then be created out of the built-in specs, and introduce a 22176 `Makefile' rule to generate the `specs' file that's going to be 22177 used at build time out of your `specs.install'. 22178 22179 22180File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 22181 2218213.2 Host Makefile Fragments 22183============================ 22184 22185The use of `x-HOST' fragments is discouraged. You should do so only if 22186there is no other mechanism to get the behavior desired. Host 22187fragments should never forcibly override variables set by the configure 22188script, as they may have been adjusted by the user. 22189 22190 Variables provided for host fragments to set include: 22191 22192`X_CFLAGS' 22193`X_CPPFLAGS' 22194 These are extra flags to pass to the C compiler and preprocessor, 22195 respectively. They are used both when building GCC, and when 22196 compiling things with the just-built GCC. 22197 22198`XCFLAGS' 22199 These are extra flags to use when building the compiler. They are 22200 not used when compiling `libgcc.a'. However, they _are_ used when 22201 recompiling the compiler with itself in later stages of a 22202 bootstrap. 22203 22204`BOOT_LDFLAGS' 22205 Flags to be passed to the linker when recompiling the compiler with 22206 itself in later stages of a bootstrap. You might need to use this 22207 if, for instance, one of the front ends needs more text space than 22208 the linker provides by default. 22209 22210`EXTRA_PROGRAMS' 22211 A list of additional programs required to use the compiler on this 22212 host, which should be compiled with GCC and installed alongside 22213 the front ends. If you set this variable, you must also provide 22214 rules to build the extra programs. 22215 22216 22217 22218File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 22219 2222014 `collect2' 22221************* 22222 22223GCC uses a utility called `collect2' on nearly all systems to arrange 22224to call various initialization functions at start time. 22225 22226 The program `collect2' works by linking the program once and looking 22227through the linker output file for symbols with particular names 22228indicating they are constructor functions. If it finds any, it creates 22229a new temporary `.c' file containing a table of them, compiles it, and 22230links the program a second time including that file. 22231 22232 The actual calls to the constructors are carried out by a subroutine 22233called `__main', which is called (automatically) at the beginning of 22234the body of `main' (provided `main' was compiled with GNU CC). Calling 22235`__main' is necessary, even when compiling C code, to allow linking C 22236and C++ object code together. (If you use `-nostdlib', you get an 22237unresolved reference to `__main', since it's defined in the standard 22238GCC library. Include `-lgcc' at the end of your compiler command line 22239to resolve this reference.) 22240 22241 The program `collect2' is installed as `ld' in the directory where 22242the passes of the compiler are installed. When `collect2' needs to 22243find the _real_ `ld', it tries the following file names: 22244 22245 * `real-ld' in the directories listed in the compiler's search 22246 directories. 22247 22248 * `real-ld' in the directories listed in the environment variable 22249 `PATH'. 22250 22251 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 22252 if specified. 22253 22254 * `ld' in the compiler's search directories, except that `collect2' 22255 will not execute itself recursively. 22256 22257 * `ld' in `PATH'. 22258 22259 "The compiler's search directories" means all the directories where 22260`gcc' searches for passes of the compiler. This includes directories 22261that you specify with `-B'. 22262 22263 Cross-compilers search a little differently: 22264 22265 * `real-ld' in the compiler's search directories. 22266 22267 * `TARGET-real-ld' in `PATH'. 22268 22269 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 22270 if specified. 22271 22272 * `ld' in the compiler's search directories. 22273 22274 * `TARGET-ld' in `PATH'. 22275 22276 `collect2' explicitly avoids running `ld' using the file name under 22277which `collect2' itself was invoked. In fact, it remembers up a list 22278of such names--in case one copy of `collect2' finds another copy (or 22279version) of `collect2' installed as `ld' in a second place in the 22280search path. 22281 22282 `collect2' searches for the utilities `nm' and `strip' using the 22283same algorithm as above for `ld'. 22284 22285 22286File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 22287 2228815 Standard Header File Directories 22289*********************************** 22290 22291`GCC_INCLUDE_DIR' means the same thing for native and cross. It is 22292where GCC stores its private include files, and also where GCC stores 22293the fixed include files. A cross compiled GCC runs `fixincludes' on 22294the header files in `$(tooldir)/include'. (If the cross compilation 22295header files need to be fixed, they must be installed before GCC is 22296built. If the cross compilation header files are already suitable for 22297GCC, nothing special need be done). 22298 22299 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. 22300It is where `g++' looks first for header files. The C++ library 22301installs only target independent header files in that directory. 22302 22303 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 22304install anything there. It is normally `/usr/local/include'. This is 22305where local additions to a packaged system should place header files. 22306 22307 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 22308install anything there. 22309 22310 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It 22311is the place for other packages to install header files that GCC will 22312use. For a cross-compiler, this is the equivalent of `/usr/include'. 22313When you build a cross-compiler, `fixincludes' processes any header 22314files in this directory. 22315 22316 22317File: gccint.info, Node: Type Information, Next: Funding, Prev: Header Dirs, Up: Top 22318 2231916 Memory Management and Type Information 22320***************************************** 22321 22322GCC uses some fairly sophisticated memory management techniques, which 22323involve determining information about GCC's data structures from GCC's 22324source code and using this information to perform garbage collection and 22325implement precompiled headers. 22326 22327 A full C parser would be too overcomplicated for this task, so a 22328limited subset of C is interpreted and special markers are used to 22329determine what parts of the source to look at. The parser can also 22330detect simple typedefs of the form `typedef struct ID1 *ID2;' and 22331`typedef int ID3;', and these don't need to be specially marked. 22332 22333 The two forms that do need to be marked are: 22334 22335struct ID1 GTY(([options])) 22336{ 22337 [fields] 22338}; 22339 22340typedef struct ID2 GTY(([options])) 22341{ 22342 [fields] 22343} ID3; 22344 22345* Menu: 22346 22347* GTY Options:: What goes inside a `GTY(())'. 22348* GGC Roots:: Making global variables GGC roots. 22349* Files:: How the generated files work. 22350 22351 22352File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information 22353 2235416.1 The Inside of a `GTY(())' 22355============================== 22356 22357Sometimes the C code is not enough to fully describe the type structure. 22358Extra information can be provided by using more `GTY' markers. These 22359markers can be placed: 22360 * In a structure definition, before the open brace; 22361 22362 * In a global variable declaration, after the keyword `static' or 22363 `extern'; and 22364 22365 * In a structure field definition, before the name of the field. 22366 22367 The format of a marker is 22368 22369GTY (([name] ([param]), [name] ([param]) ...)) 22370 The parameter is either a string or a type name. 22371 22372 When the parameter is a string, often it is a fragment of C code. 22373Three special escapes may be available: 22374 22375`%h' 22376 This expands to an expression that evaluates to the current 22377 structure. 22378 22379`%1' 22380 This expands to an expression that evaluates to the structure that 22381 immediately contains the current structure. 22382 22383`%0' 22384 This expands to an expression that evaluates to the outermost 22385 structure that contains the current structure. 22386 22387`%a' 22388 This expands to the string of the form `[i1][i2]...' that indexes 22389 the array item currently being marked. For instance, if the field 22390 being marked is `foo', then `%1.foo%a' is the same as `%h'. 22391 22392 The available options are: 22393 22394`length' 22395 There are two places the type machinery will need to be explicitly 22396 told the length of an array. The first case is when a structure 22397 ends in a variable-length array, like this: 22398 struct rtvec_def GTY(()) { 22399 int num_elem; /* number of elements */ 22400 rtx GTY ((length ("%h.num_elem"))) elem[1]; 22401 }; 22402 In this case, the `length' option is used to override the 22403 specified array length (which should usually be `1'). The 22404 parameter of the option is a fragment of C code that calculates 22405 the length. 22406 22407 The second case is when a structure or a global variable contains a 22408 pointer to an array, like this: 22409 tree * 22410 GTY ((length ("%h.regno_pointer_align_length"))) regno_decl; 22411 In this case, `regno_decl' has been allocated by writing something 22412 like 22413 x->regno_decl = 22414 ggc_alloc (x->regno_pointer_align_length * sizeof (tree)); 22415 and the `length' provides the length of the field. 22416 22417 This second use of `length' also works on global variables, like: 22418 static GTY((length ("reg_base_value_size"))) 22419 rtx *reg_base_value; 22420 22421`skip' 22422 If `skip' is applied to a field, the type machinery will ignore it. 22423 This is somewhat dangerous; the only safe use is in a union when 22424 one field really isn't ever used. 22425 22426`desc' 22427`tag' 22428`default' 22429 The type machinery needs to be told which field of a `union' is 22430 currently active. This is done by giving each field a constant 22431 `tag' value, and then specifying a discriminator using `desc'. 22432 The value of the expression given by `desc' is compared against 22433 each `tag' value, each of which should be different. If no `tag' 22434 is matched, the field marked with `default' is used if there is 22435 one, otherwise no field in the union will be marked. 22436 22437 In the `desc' option, the "current structure" is the union that it 22438 discriminates. Use `%1' to mean the structure containing it. 22439 (There are no escapes available to the `tag' option, since it's 22440 supposed to be a constant.) 22441 22442 For example, 22443 struct tree_binding GTY(()) 22444 { 22445 struct tree_common common; 22446 union tree_binding_u { 22447 tree GTY ((tag ("0"))) scope; 22448 struct cp_binding_level * GTY ((tag ("1"))) level; 22449 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 22450 tree value; 22451 }; 22452 22453 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 22454 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type 22455 mechanism will treat the field `level' as being present and if 0, 22456 will treat the field `scope' as being present. 22457 22458`param_is' 22459`use_param' 22460 Sometimes it's convenient to define some data structure to work on 22461 generic pointers (that is, `PTR') and then use it with a specific 22462 type. `param_is' specifies the real type pointed to, and 22463 `use_param' says where in the generic data structure that type 22464 should be put. 22465 22466 For instance, to have a `htab_t' that points to trees, one should 22467 write 22468 htab_t GTY ((param_is (union tree_node))) ict; 22469 22470`paramN_is' 22471`use_paramN' 22472 In more complicated cases, the data structure might need to work on 22473 several different types, which might not necessarily all be 22474 pointers. For this, `param1_is' through `param9_is' may be used to 22475 specify the real type of a field identified by `use_param1' through 22476 `use_param9'. 22477 22478`use_params' 22479 When a structure contains another structure that is parameterized, 22480 there's no need to do anything special, the inner structure 22481 inherits the parameters of the outer one. When a structure 22482 contains a pointer to a parameterized structure, the type 22483 machinery won't automatically detect this (it could, it just 22484 doesn't yet), so it's necessary to tell it that the pointed-to 22485 structure should use the same parameters as the outer structure. 22486 This is done by marking the pointer with the `use_params' option. 22487 22488`deletable' 22489 `deletable', when applied to a global variable, indicates that when 22490 garbage collection runs, there's no need to mark anything pointed 22491 to by this variable, it can just be set to `NULL' instead. This 22492 is used to keep a list of free structures around for re-use. 22493 22494`if_marked' 22495 Suppose you want some kinds of object to be unique, and so you put 22496 them in a hash table. If garbage collection marks the hash table, 22497 these objects will never be freed, even if the last other 22498 reference to them goes away. GGC has special handling to deal 22499 with this: if you use the `if_marked' option on a global hash 22500 table, GGC will call the routine whose name is the parameter to 22501 the option on each hash table entry. If the routine returns 22502 nonzero, the hash table entry will be marked as usual. If the 22503 routine returns zero, the hash table entry will be deleted. 22504 22505 The routine `ggc_marked_p' can be used to determine if an element 22506 has been marked already; in fact, the usual case is to use 22507 `if_marked ("ggc_marked_p")'. 22508 22509`maybe_undef' 22510 When applied to a field, `maybe_undef' indicates that it's OK if 22511 the structure that this fields points to is never defined, so long 22512 as this field is always `NULL'. This is used to avoid requiring 22513 backends to define certain optional structures. It doesn't work 22514 with language frontends. 22515 22516`chain_next' 22517`chain_prev' 22518 It's helpful for the type machinery to know if objects are often 22519 chained together in long lists; this lets it generate code that 22520 uses less stack space by iterating along the list instead of 22521 recursing down it. `chain_next' is an expression for the next 22522 item in the list, `chain_prev' is an expression for the previous 22523 item. The machinery requires that taking the next item of the 22524 previous item gives the original item. 22525 22526`reorder' 22527 Some data structures depend on the relative ordering of pointers. 22528 If the type machinery needs to change that ordering, it will call 22529 the function referenced by the `reorder' option, before changing 22530 the pointers in the object that's pointed to by the field the 22531 option applies to. The function must be of the type `void ()(void 22532 *, void *, gt_pointer_operator, void *)'. The second parameter is 22533 the pointed-to object; the third parameter is a routine that, 22534 given a pointer, can update it to its new value. The fourth 22535 parameter is a cookie to be passed to the third parameter. The 22536 first parameter is the structure that contains the object, or the 22537 object itself if it is a structure. 22538 22539 No data structure may depend on the absolute value of pointers. 22540 Even relying on relative orderings and using `reorder' functions 22541 can be expensive. It is better to depend on properties of the 22542 data, like an ID number or the hash of a string instead. 22543 22544`special' 22545 The `special' option is used for those bizarre cases that are just 22546 too hard to deal with otherwise. Don't use it for new code. 22547 22548 22549 22550File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information 22551 2255216.2 Marking Roots for the Garbage Collector 22553============================================ 22554 22555In addition to keeping track of types, the type machinery also locates 22556the global variables that the garbage collector starts at. There are 22557two syntaxes it accepts to indicate a root: 22558 22559 1. extern GTY (([options])) [type] ID; 22560 22561 2. static GTY (([options])) [type] ID; 22562 22563 These are the only syntaxes that are accepted. In particular, if you 22564want to mark a variable that is only declared as 22565 22566int ID; 22567 or similar, you should either make it `static' or you should create a 22568`extern' declaration in a header file somewhere. 22569 22570 22571File: gccint.info, Node: Files, Prev: GGC Roots, Up: Type Information 22572 2257316.3 Source Files Containing Type Information 22574============================================= 22575 22576Whenever you add `GTY' markers to a new source file, there are three 22577things you need to do: 22578 22579 1. You need to add the file to the list of source files the type 22580 machinery scans. There are three cases: 22581 22582 a. For a back-end file, this is usually done automatically; if 22583 not, you should add it to `target_gtfiles' in the appropriate 22584 port's entries in `config.gcc'. 22585 22586 b. For files shared by all front ends, this is done by adding the 22587 filename to the `GTFILES' variable in `Makefile.in'. 22588 22589 c. For any other file used by a front end, this is done by 22590 adding the filename to the `gtfiles' variable defined in 22591 `config-lang.in'. For C, the file is `c-config-lang.in'. 22592 This list should include all files that have GTY macros in 22593 them that are used in that front end, other than those 22594 defined in the previous list items. For example, it is 22595 common for front end writers to use `c-common.c' and other 22596 files from the C front end, and these should be included in 22597 the `gtfiles' variable for such front ends. 22598 22599 22600 2. If the file was a header file, you'll need to check that it's 22601 included in the right place to be visible to the generated files. 22602 For a back-end header file, this should be done automatically. 22603 For a front-end header file, it needs to be included by the same 22604 file that includes `gtype-LANG.h'. For other header files, it 22605 needs to be included in `gtype-desc.c', which is a generated file, 22606 so add it to `ifiles' in `open_base_file' in `gengtype.c'. 22607 22608 For source files that aren't header files, the machinery will 22609 generate a header file that should be included in the source file 22610 you just changed. The file will be called `gt-PATH.h' where PATH 22611 is the pathname relative to the `gcc' directory with slashes 22612 replaced by -, so for example the header file to be included in 22613 `objc/objc-parse.c' is called `gt-objc-objc-parse.c'. The 22614 generated header file should be included after everything else in 22615 the source file. Don't forget to mention this file as a 22616 dependency in the `Makefile'! 22617 22618 3. If a new `gt-PATH.h' file is needed, you need to arrange to add a 22619 `Makefile' rule that will ensure this file can be built. This is 22620 done by making it a dependency of `s-gtype', like this: 22621 gt-path.h : s-gtype ; @true 22622 22623 For language frontends, there is another file that needs to be 22624included somewhere. It will be called `gtype-LANG.h', where LANG is 22625the name of the subdirectory the language is contained in. It will 22626need `Makefile' rules just like the other generated files. 22627 22628 22629File: gccint.info, Node: Funding, Next: GNU Project, Prev: Type Information, Up: Top 22630 22631Funding Free Software 22632********************* 22633 22634If you want to have more free software a few years from now, it makes 22635sense for you to help encourage people to contribute funds for its 22636development. The most effective approach known is to encourage 22637commercial redistributors to donate. 22638 22639 Users of free software systems can boost the pace of development by 22640encouraging for-a-fee distributors to donate part of their selling price 22641to free software developers--the Free Software Foundation, and others. 22642 22643 The way to convince distributors to do this is to demand it and 22644expect it from them. So when you compare distributors, judge them 22645partly by how much they give to free software development. Show 22646distributors they must compete to be the one who gives the most. 22647 22648 To make this approach work, you must insist on numbers that you can 22649compare, such as, "We will donate ten dollars to the Frobnitz project 22650for each disk sold." Don't be satisfied with a vague promise, such as 22651"A portion of the profits are donated," since it doesn't give a basis 22652for comparison. 22653 22654 Even a precise fraction "of the profits from this disk" is not very 22655meaningful, since creative accounting and unrelated business decisions 22656can greatly alter what fraction of the sales price counts as profit. 22657If the price you pay is $50, ten percent of the profit is probably less 22658than a dollar; it might be a few cents, or nothing at all. 22659 22660 Some redistributors do development work themselves. This is useful 22661too; but to keep everyone honest, you need to inquire how much they do, 22662and what kind. Some kinds of development make much more long-term 22663difference than others. For example, maintaining a separate version of 22664a program contributes very little; maintaining the standard version of a 22665program for the whole community contributes much. Easy new ports 22666contribute little, since someone else would surely do them; difficult 22667ports such as adding a new CPU to the GNU Compiler Collection 22668contribute more; major new features or packages contribute the most. 22669 22670 By establishing the idea that supporting further development is "the 22671proper thing to do" when distributing free software for a fee, we can 22672assure a steady flow of resources into making more free software. 22673 22674 Copyright (C) 1994 Free Software Foundation, Inc. 22675 Verbatim copying and redistribution of this section is permitted 22676 without royalty; alteration is not permitted. 22677 22678 22679File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 22680 22681The GNU Project and GNU/Linux 22682***************************** 22683 22684The GNU Project was launched in 1984 to develop a complete Unix-like 22685operating system which is free software: the GNU system. (GNU is a 22686recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 22687Variants of the GNU operating system, which use the kernel Linux, are 22688now widely used; though these systems are often referred to as "Linux", 22689they are more accurately called GNU/Linux systems. 22690 22691 For more information, see: 22692 `http://www.gnu.org/' 22693 `http://www.gnu.org/gnu/linux-and-gnu.html' 22694 22695 22696File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 22697 22698GNU GENERAL PUBLIC LICENSE 22699************************** 22700 22701 Version 2, June 1991 22702 22703 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 22704 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA 22705 22706 Everyone is permitted to copy and distribute verbatim copies 22707 of this license document, but changing it is not allowed. 22708 22709Preamble 22710======== 22711 22712The licenses for most software are designed to take away your freedom 22713to share and change it. By contrast, the GNU General Public License is 22714intended to guarantee your freedom to share and change free 22715software--to make sure the software is free for all its users. This 22716General Public License applies to most of the Free Software 22717Foundation's software and to any other program whose authors commit to 22718using it. (Some other Free Software Foundation software is covered by 22719the GNU Library General Public License instead.) You can apply it to 22720your programs, too. 22721 22722 When we speak of free software, we are referring to freedom, not 22723price. Our General Public Licenses are designed to make sure that you 22724have the freedom to distribute copies of free software (and charge for 22725this service if you wish), that you receive source code or can get it 22726if you want it, that you can change the software or use pieces of it in 22727new free programs; and that you know you can do these things. 22728 22729 To protect your rights, we need to make restrictions that forbid 22730anyone to deny you these rights or to ask you to surrender the rights. 22731These restrictions translate to certain responsibilities for you if you 22732distribute copies of the software, or if you modify it. 22733 22734 For example, if you distribute copies of such a program, whether 22735gratis or for a fee, you must give the recipients all the rights that 22736you have. You must make sure that they, too, receive or can get the 22737source code. And you must show them these terms so they know their 22738rights. 22739 22740 We protect your rights with two steps: (1) copyright the software, 22741and (2) offer you this license which gives you legal permission to copy, 22742distribute and/or modify the software. 22743 22744 Also, for each author's protection and ours, we want to make certain 22745that everyone understands that there is no warranty for this free 22746software. If the software is modified by someone else and passed on, we 22747want its recipients to know that what they have is not the original, so 22748that any problems introduced by others will not reflect on the original 22749authors' reputations. 22750 22751 Finally, any free program is threatened constantly by software 22752patents. We wish to avoid the danger that redistributors of a free 22753program will individually obtain patent licenses, in effect making the 22754program proprietary. To prevent this, we have made it clear that any 22755patent must be licensed for everyone's free use or not licensed at all. 22756 22757 The precise terms and conditions for copying, distribution and 22758modification follow. 22759 22760 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 22761 0. This License applies to any program or other work which contains a 22762 notice placed by the copyright holder saying it may be distributed 22763 under the terms of this General Public License. The "Program", 22764 below, refers to any such program or work, and a "work based on 22765 the Program" means either the Program or any derivative work under 22766 copyright law: that is to say, a work containing the Program or a 22767 portion of it, either verbatim or with modifications and/or 22768 translated into another language. (Hereinafter, translation is 22769 included without limitation in the term "modification".) Each 22770 licensee is addressed as "you". 22771 22772 Activities other than copying, distribution and modification are 22773 not covered by this License; they are outside its scope. The act 22774 of running the Program is not restricted, and the output from the 22775 Program is covered only if its contents constitute a work based on 22776 the Program (independent of having been made by running the 22777 Program). Whether that is true depends on what the Program does. 22778 22779 1. You may copy and distribute verbatim copies of the Program's 22780 source code as you receive it, in any medium, provided that you 22781 conspicuously and appropriately publish on each copy an appropriate 22782 copyright notice and disclaimer of warranty; keep intact all the 22783 notices that refer to this License and to the absence of any 22784 warranty; and give any other recipients of the Program a copy of 22785 this License along with the Program. 22786 22787 You may charge a fee for the physical act of transferring a copy, 22788 and you may at your option offer warranty protection in exchange 22789 for a fee. 22790 22791 2. You may modify your copy or copies of the Program or any portion 22792 of it, thus forming a work based on the Program, and copy and 22793 distribute such modifications or work under the terms of Section 1 22794 above, provided that you also meet all of these conditions: 22795 22796 a. You must cause the modified files to carry prominent notices 22797 stating that you changed the files and the date of any change. 22798 22799 b. You must cause any work that you distribute or publish, that 22800 in whole or in part contains or is derived from the Program 22801 or any part thereof, to be licensed as a whole at no charge 22802 to all third parties under the terms of this License. 22803 22804 c. If the modified program normally reads commands interactively 22805 when run, you must cause it, when started running for such 22806 interactive use in the most ordinary way, to print or display 22807 an announcement including an appropriate copyright notice and 22808 a notice that there is no warranty (or else, saying that you 22809 provide a warranty) and that users may redistribute the 22810 program under these conditions, and telling the user how to 22811 view a copy of this License. (Exception: if the Program 22812 itself is interactive but does not normally print such an 22813 announcement, your work based on the Program is not required 22814 to print an announcement.) 22815 22816 These requirements apply to the modified work as a whole. If 22817 identifiable sections of that work are not derived from the 22818 Program, and can be reasonably considered independent and separate 22819 works in themselves, then this License, and its terms, do not 22820 apply to those sections when you distribute them as separate 22821 works. But when you distribute the same sections as part of a 22822 whole which is a work based on the Program, the distribution of 22823 the whole must be on the terms of this License, whose permissions 22824 for other licensees extend to the entire whole, and thus to each 22825 and every part regardless of who wrote it. 22826 22827 Thus, it is not the intent of this section to claim rights or 22828 contest your rights to work written entirely by you; rather, the 22829 intent is to exercise the right to control the distribution of 22830 derivative or collective works based on the Program. 22831 22832 In addition, mere aggregation of another work not based on the 22833 Program with the Program (or with a work based on the Program) on 22834 a volume of a storage or distribution medium does not bring the 22835 other work under the scope of this License. 22836 22837 3. You may copy and distribute the Program (or a work based on it, 22838 under Section 2) in object code or executable form under the terms 22839 of Sections 1 and 2 above provided that you also do one of the 22840 following: 22841 22842 a. Accompany it with the complete corresponding machine-readable 22843 source code, which must be distributed under the terms of 22844 Sections 1 and 2 above on a medium customarily used for 22845 software interchange; or, 22846 22847 b. Accompany it with a written offer, valid for at least three 22848 years, to give any third party, for a charge no more than your 22849 cost of physically performing source distribution, a complete 22850 machine-readable copy of the corresponding source code, to be 22851 distributed under the terms of Sections 1 and 2 above on a 22852 medium customarily used for software interchange; or, 22853 22854 c. Accompany it with the information you received as to the offer 22855 to distribute corresponding source code. (This alternative is 22856 allowed only for noncommercial distribution and only if you 22857 received the program in object code or executable form with 22858 such an offer, in accord with Subsection b above.) 22859 22860 The source code for a work means the preferred form of the work for 22861 making modifications to it. For an executable work, complete 22862 source code means all the source code for all modules it contains, 22863 plus any associated interface definition files, plus the scripts 22864 used to control compilation and installation of the executable. 22865 However, as a special exception, the source code distributed need 22866 not include anything that is normally distributed (in either 22867 source or binary form) with the major components (compiler, 22868 kernel, and so on) of the operating system on which the executable 22869 runs, unless that component itself accompanies the executable. 22870 22871 If distribution of executable or object code is made by offering 22872 access to copy from a designated place, then offering equivalent 22873 access to copy the source code from the same place counts as 22874 distribution of the source code, even though third parties are not 22875 compelled to copy the source along with the object code. 22876 22877 4. You may not copy, modify, sublicense, or distribute the Program 22878 except as expressly provided under this License. Any attempt 22879 otherwise to copy, modify, sublicense or distribute the Program is 22880 void, and will automatically terminate your rights under this 22881 License. However, parties who have received copies, or rights, 22882 from you under this License will not have their licenses 22883 terminated so long as such parties remain in full compliance. 22884 22885 5. You are not required to accept this License, since you have not 22886 signed it. However, nothing else grants you permission to modify 22887 or distribute the Program or its derivative works. These actions 22888 are prohibited by law if you do not accept this License. 22889 Therefore, by modifying or distributing the Program (or any work 22890 based on the Program), you indicate your acceptance of this 22891 License to do so, and all its terms and conditions for copying, 22892 distributing or modifying the Program or works based on it. 22893 22894 6. Each time you redistribute the Program (or any work based on the 22895 Program), the recipient automatically receives a license from the 22896 original licensor to copy, distribute or modify the Program 22897 subject to these terms and conditions. You may not impose any 22898 further restrictions on the recipients' exercise of the rights 22899 granted herein. You are not responsible for enforcing compliance 22900 by third parties to this License. 22901 22902 7. If, as a consequence of a court judgment or allegation of patent 22903 infringement or for any other reason (not limited to patent 22904 issues), conditions are imposed on you (whether by court order, 22905 agreement or otherwise) that contradict the conditions of this 22906 License, they do not excuse you from the conditions of this 22907 License. If you cannot distribute so as to satisfy simultaneously 22908 your obligations under this License and any other pertinent 22909 obligations, then as a consequence you may not distribute the 22910 Program at all. For example, if a patent license would not permit 22911 royalty-free redistribution of the Program by all those who 22912 receive copies directly or indirectly through you, then the only 22913 way you could satisfy both it and this License would be to refrain 22914 entirely from distribution of the Program. 22915 22916 If any portion of this section is held invalid or unenforceable 22917 under any particular circumstance, the balance of the section is 22918 intended to apply and the section as a whole is intended to apply 22919 in other circumstances. 22920 22921 It is not the purpose of this section to induce you to infringe any 22922 patents or other property right claims or to contest validity of 22923 any such claims; this section has the sole purpose of protecting 22924 the integrity of the free software distribution system, which is 22925 implemented by public license practices. Many people have made 22926 generous contributions to the wide range of software distributed 22927 through that system in reliance on consistent application of that 22928 system; it is up to the author/donor to decide if he or she is 22929 willing to distribute software through any other system and a 22930 licensee cannot impose that choice. 22931 22932 This section is intended to make thoroughly clear what is believed 22933 to be a consequence of the rest of this License. 22934 22935 8. If the distribution and/or use of the Program is restricted in 22936 certain countries either by patents or by copyrighted interfaces, 22937 the original copyright holder who places the Program under this 22938 License may add an explicit geographical distribution limitation 22939 excluding those countries, so that distribution is permitted only 22940 in or among countries not thus excluded. In such case, this 22941 License incorporates the limitation as if written in the body of 22942 this License. 22943 22944 9. The Free Software Foundation may publish revised and/or new 22945 versions of the General Public License from time to time. Such 22946 new versions will be similar in spirit to the present version, but 22947 may differ in detail to address new problems or concerns. 22948 22949 Each version is given a distinguishing version number. If the 22950 Program specifies a version number of this License which applies 22951 to it and "any later version", you have the option of following 22952 the terms and conditions either of that version or of any later 22953 version published by the Free Software Foundation. If the Program 22954 does not specify a version number of this License, you may choose 22955 any version ever published by the Free Software Foundation. 22956 22957 10. If you wish to incorporate parts of the Program into other free 22958 programs whose distribution conditions are different, write to the 22959 author to ask for permission. For software which is copyrighted 22960 by the Free Software Foundation, write to the Free Software 22961 Foundation; we sometimes make exceptions for this. Our decision 22962 will be guided by the two goals of preserving the free status of 22963 all derivatives of our free software and of promoting the sharing 22964 and reuse of software generally. 22965 22966 NO WARRANTY 22967 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO 22968 WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE 22969 LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT 22970 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT 22971 WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT 22972 NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 22973 FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE 22974 QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE 22975 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY 22976 SERVICING, REPAIR OR CORRECTION. 22977 22978 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 22979 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY 22980 MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE 22981 LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, 22982 INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR 22983 INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF 22984 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU 22985 OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY 22986 OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN 22987 ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 22988 22989 END OF TERMS AND CONDITIONS 22990How to Apply These Terms to Your New Programs 22991============================================= 22992 22993If you develop a new program, and you want it to be of the greatest 22994possible use to the public, the best way to achieve this is to make it 22995free software which everyone can redistribute and change under these 22996terms. 22997 22998 To do so, attach the following notices to the program. It is safest 22999to attach them to the start of each source file to most effectively 23000convey the exclusion of warranty; and each file should have at least 23001the "copyright" line and a pointer to where the full notice is found. 23002 23003 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 23004 Copyright (C) YEAR NAME OF AUTHOR 23005 23006 This program is free software; you can redistribute it and/or modify 23007 it under the terms of the GNU General Public License as published by 23008 the Free Software Foundation; either version 2 of the License, or 23009 (at your option) any later version. 23010 23011 This program is distributed in the hope that it will be useful, 23012 but WITHOUT ANY WARRANTY; without even the implied warranty of 23013 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 23014 GNU General Public License for more details. 23015 23016 You should have received a copy of the GNU General Public License 23017 along with this program; if not, write to the Free Software Foundation, 23018 Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. 23019 23020 Also add information on how to contact you by electronic and paper 23021mail. 23022 23023 If the program is interactive, make it output a short notice like 23024this when it starts in an interactive mode: 23025 23026 Gnomovision version 69, Copyright (C) YEAR NAME OF AUTHOR 23027 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details 23028 type `show w'. 23029 This is free software, and you are welcome to redistribute it 23030 under certain conditions; type `show c' for details. 23031 23032 The hypothetical commands `show w' and `show c' should show the 23033appropriate parts of the General Public License. Of course, the 23034commands you use may be called something other than `show w' and `show 23035c'; they could even be mouse-clicks or menu items--whatever suits your 23036program. 23037 23038 You should also get your employer (if you work as a programmer) or 23039your school, if any, to sign a "copyright disclaimer" for the program, 23040if necessary. Here is a sample; alter the names: 23041 23042 Yoyodyne, Inc., hereby disclaims all copyright interest in the program 23043 `Gnomovision' (which makes passes at compilers) written by James Hacker. 23044 23045 SIGNATURE OF TY COON, 1 April 1989 23046 Ty Coon, President of Vice 23047 23048 This General Public License does not permit incorporating your 23049program into proprietary programs. If your program is a subroutine 23050library, you may consider it more useful to permit linking proprietary 23051applications with the library. If this is what you want to do, use the 23052GNU Library General Public License instead of this License. 23053 23054 23055File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 23056 23057GNU Free Documentation License 23058****************************** 23059 23060 Version 1.2, November 2002 23061 23062 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 23063 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA 23064 23065 Everyone is permitted to copy and distribute verbatim copies 23066 of this license document, but changing it is not allowed. 23067 23068 0. PREAMBLE 23069 23070 The purpose of this License is to make a manual, textbook, or other 23071 functional and useful document "free" in the sense of freedom: to 23072 assure everyone the effective freedom to copy and redistribute it, 23073 with or without modifying it, either commercially or 23074 noncommercially. Secondarily, this License preserves for the 23075 author and publisher a way to get credit for their work, while not 23076 being considered responsible for modifications made by others. 23077 23078 This License is a kind of "copyleft", which means that derivative 23079 works of the document must themselves be free in the same sense. 23080 It complements the GNU General Public License, which is a copyleft 23081 license designed for free software. 23082 23083 We have designed this License in order to use it for manuals for 23084 free software, because free software needs free documentation: a 23085 free program should come with manuals providing the same freedoms 23086 that the software does. But this License is not limited to 23087 software manuals; it can be used for any textual work, regardless 23088 of subject matter or whether it is published as a printed book. 23089 We recommend this License principally for works whose purpose is 23090 instruction or reference. 23091 23092 1. APPLICABILITY AND DEFINITIONS 23093 23094 This License applies to any manual or other work, in any medium, 23095 that contains a notice placed by the copyright holder saying it 23096 can be distributed under the terms of this License. Such a notice 23097 grants a world-wide, royalty-free license, unlimited in duration, 23098 to use that work under the conditions stated herein. The 23099 "Document", below, refers to any such manual or work. Any member 23100 of the public is a licensee, and is addressed as "you". You 23101 accept the license if you copy, modify or distribute the work in a 23102 way requiring permission under copyright law. 23103 23104 A "Modified Version" of the Document means any work containing the 23105 Document or a portion of it, either copied verbatim, or with 23106 modifications and/or translated into another language. 23107 23108 A "Secondary Section" is a named appendix or a front-matter section 23109 of the Document that deals exclusively with the relationship of the 23110 publishers or authors of the Document to the Document's overall 23111 subject (or to related matters) and contains nothing that could 23112 fall directly within that overall subject. (Thus, if the Document 23113 is in part a textbook of mathematics, a Secondary Section may not 23114 explain any mathematics.) The relationship could be a matter of 23115 historical connection with the subject or with related matters, or 23116 of legal, commercial, philosophical, ethical or political position 23117 regarding them. 23118 23119 The "Invariant Sections" are certain Secondary Sections whose 23120 titles are designated, as being those of Invariant Sections, in 23121 the notice that says that the Document is released under this 23122 License. If a section does not fit the above definition of 23123 Secondary then it is not allowed to be designated as Invariant. 23124 The Document may contain zero Invariant Sections. If the Document 23125 does not identify any Invariant Sections then there are none. 23126 23127 The "Cover Texts" are certain short passages of text that are 23128 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 23129 that says that the Document is released under this License. A 23130 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 23131 be at most 25 words. 23132 23133 A "Transparent" copy of the Document means a machine-readable copy, 23134 represented in a format whose specification is available to the 23135 general public, that is suitable for revising the document 23136 straightforwardly with generic text editors or (for images 23137 composed of pixels) generic paint programs or (for drawings) some 23138 widely available drawing editor, and that is suitable for input to 23139 text formatters or for automatic translation to a variety of 23140 formats suitable for input to text formatters. A copy made in an 23141 otherwise Transparent file format whose markup, or absence of 23142 markup, has been arranged to thwart or discourage subsequent 23143 modification by readers is not Transparent. An image format is 23144 not Transparent if used for any substantial amount of text. A 23145 copy that is not "Transparent" is called "Opaque". 23146 23147 Examples of suitable formats for Transparent copies include plain 23148 ASCII without markup, Texinfo input format, LaTeX input format, 23149 SGML or XML using a publicly available DTD, and 23150 standard-conforming simple HTML, PostScript or PDF designed for 23151 human modification. Examples of transparent image formats include 23152 PNG, XCF and JPG. Opaque formats include proprietary formats that 23153 can be read and edited only by proprietary word processors, SGML or 23154 XML for which the DTD and/or processing tools are not generally 23155 available, and the machine-generated HTML, PostScript or PDF 23156 produced by some word processors for output purposes only. 23157 23158 The "Title Page" means, for a printed book, the title page itself, 23159 plus such following pages as are needed to hold, legibly, the 23160 material this License requires to appear in the title page. For 23161 works in formats which do not have any title page as such, "Title 23162 Page" means the text near the most prominent appearance of the 23163 work's title, preceding the beginning of the body of the text. 23164 23165 A section "Entitled XYZ" means a named subunit of the Document 23166 whose title either is precisely XYZ or contains XYZ in parentheses 23167 following text that translates XYZ in another language. (Here XYZ 23168 stands for a specific section name mentioned below, such as 23169 "Acknowledgements", "Dedications", "Endorsements", or "History".) 23170 To "Preserve the Title" of such a section when you modify the 23171 Document means that it remains a section "Entitled XYZ" according 23172 to this definition. 23173 23174 The Document may include Warranty Disclaimers next to the notice 23175 which states that this License applies to the Document. These 23176 Warranty Disclaimers are considered to be included by reference in 23177 this License, but only as regards disclaiming warranties: any other 23178 implication that these Warranty Disclaimers may have is void and 23179 has no effect on the meaning of this License. 23180 23181 2. VERBATIM COPYING 23182 23183 You may copy and distribute the Document in any medium, either 23184 commercially or noncommercially, provided that this License, the 23185 copyright notices, and the license notice saying this License 23186 applies to the Document are reproduced in all copies, and that you 23187 add no other conditions whatsoever to those of this License. You 23188 may not use technical measures to obstruct or control the reading 23189 or further copying of the copies you make or distribute. However, 23190 you may accept compensation in exchange for copies. If you 23191 distribute a large enough number of copies you must also follow 23192 the conditions in section 3. 23193 23194 You may also lend copies, under the same conditions stated above, 23195 and you may publicly display copies. 23196 23197 3. COPYING IN QUANTITY 23198 23199 If you publish printed copies (or copies in media that commonly 23200 have printed covers) of the Document, numbering more than 100, and 23201 the Document's license notice requires Cover Texts, you must 23202 enclose the copies in covers that carry, clearly and legibly, all 23203 these Cover Texts: Front-Cover Texts on the front cover, and 23204 Back-Cover Texts on the back cover. Both covers must also clearly 23205 and legibly identify you as the publisher of these copies. The 23206 front cover must present the full title with all words of the 23207 title equally prominent and visible. You may add other material 23208 on the covers in addition. Copying with changes limited to the 23209 covers, as long as they preserve the title of the Document and 23210 satisfy these conditions, can be treated as verbatim copying in 23211 other respects. 23212 23213 If the required texts for either cover are too voluminous to fit 23214 legibly, you should put the first ones listed (as many as fit 23215 reasonably) on the actual cover, and continue the rest onto 23216 adjacent pages. 23217 23218 If you publish or distribute Opaque copies of the Document 23219 numbering more than 100, you must either include a 23220 machine-readable Transparent copy along with each Opaque copy, or 23221 state in or with each Opaque copy a computer-network location from 23222 which the general network-using public has access to download 23223 using public-standard network protocols a complete Transparent 23224 copy of the Document, free of added material. If you use the 23225 latter option, you must take reasonably prudent steps, when you 23226 begin distribution of Opaque copies in quantity, to ensure that 23227 this Transparent copy will remain thus accessible at the stated 23228 location until at least one year after the last time you 23229 distribute an Opaque copy (directly or through your agents or 23230 retailers) of that edition to the public. 23231 23232 It is requested, but not required, that you contact the authors of 23233 the Document well before redistributing any large number of 23234 copies, to give them a chance to provide you with an updated 23235 version of the Document. 23236 23237 4. MODIFICATIONS 23238 23239 You may copy and distribute a Modified Version of the Document 23240 under the conditions of sections 2 and 3 above, provided that you 23241 release the Modified Version under precisely this License, with 23242 the Modified Version filling the role of the Document, thus 23243 licensing distribution and modification of the Modified Version to 23244 whoever possesses a copy of it. In addition, you must do these 23245 things in the Modified Version: 23246 23247 A. Use in the Title Page (and on the covers, if any) a title 23248 distinct from that of the Document, and from those of 23249 previous versions (which should, if there were any, be listed 23250 in the History section of the Document). You may use the 23251 same title as a previous version if the original publisher of 23252 that version gives permission. 23253 23254 B. List on the Title Page, as authors, one or more persons or 23255 entities responsible for authorship of the modifications in 23256 the Modified Version, together with at least five of the 23257 principal authors of the Document (all of its principal 23258 authors, if it has fewer than five), unless they release you 23259 from this requirement. 23260 23261 C. State on the Title page the name of the publisher of the 23262 Modified Version, as the publisher. 23263 23264 D. Preserve all the copyright notices of the Document. 23265 23266 E. Add an appropriate copyright notice for your modifications 23267 adjacent to the other copyright notices. 23268 23269 F. Include, immediately after the copyright notices, a license 23270 notice giving the public permission to use the Modified 23271 Version under the terms of this License, in the form shown in 23272 the Addendum below. 23273 23274 G. Preserve in that license notice the full lists of Invariant 23275 Sections and required Cover Texts given in the Document's 23276 license notice. 23277 23278 H. Include an unaltered copy of this License. 23279 23280 I. Preserve the section Entitled "History", Preserve its Title, 23281 and add to it an item stating at least the title, year, new 23282 authors, and publisher of the Modified Version as given on 23283 the Title Page. If there is no section Entitled "History" in 23284 the Document, create one stating the title, year, authors, 23285 and publisher of the Document as given on its Title Page, 23286 then add an item describing the Modified Version as stated in 23287 the previous sentence. 23288 23289 J. Preserve the network location, if any, given in the Document 23290 for public access to a Transparent copy of the Document, and 23291 likewise the network locations given in the Document for 23292 previous versions it was based on. These may be placed in 23293 the "History" section. You may omit a network location for a 23294 work that was published at least four years before the 23295 Document itself, or if the original publisher of the version 23296 it refers to gives permission. 23297 23298 K. For any section Entitled "Acknowledgements" or "Dedications", 23299 Preserve the Title of the section, and preserve in the 23300 section all the substance and tone of each of the contributor 23301 acknowledgements and/or dedications given therein. 23302 23303 L. Preserve all the Invariant Sections of the Document, 23304 unaltered in their text and in their titles. Section numbers 23305 or the equivalent are not considered part of the section 23306 titles. 23307 23308 M. Delete any section Entitled "Endorsements". Such a section 23309 may not be included in the Modified Version. 23310 23311 N. Do not retitle any existing section to be Entitled 23312 "Endorsements" or to conflict in title with any Invariant 23313 Section. 23314 23315 O. Preserve any Warranty Disclaimers. 23316 23317 If the Modified Version includes new front-matter sections or 23318 appendices that qualify as Secondary Sections and contain no 23319 material copied from the Document, you may at your option 23320 designate some or all of these sections as invariant. To do this, 23321 add their titles to the list of Invariant Sections in the Modified 23322 Version's license notice. These titles must be distinct from any 23323 other section titles. 23324 23325 You may add a section Entitled "Endorsements", provided it contains 23326 nothing but endorsements of your Modified Version by various 23327 parties--for example, statements of peer review or that the text 23328 has been approved by an organization as the authoritative 23329 definition of a standard. 23330 23331 You may add a passage of up to five words as a Front-Cover Text, 23332 and a passage of up to 25 words as a Back-Cover Text, to the end 23333 of the list of Cover Texts in the Modified Version. Only one 23334 passage of Front-Cover Text and one of Back-Cover Text may be 23335 added by (or through arrangements made by) any one entity. If the 23336 Document already includes a cover text for the same cover, 23337 previously added by you or by arrangement made by the same entity 23338 you are acting on behalf of, you may not add another; but you may 23339 replace the old one, on explicit permission from the previous 23340 publisher that added the old one. 23341 23342 The author(s) and publisher(s) of the Document do not by this 23343 License give permission to use their names for publicity for or to 23344 assert or imply endorsement of any Modified Version. 23345 23346 5. COMBINING DOCUMENTS 23347 23348 You may combine the Document with other documents released under 23349 this License, under the terms defined in section 4 above for 23350 modified versions, provided that you include in the combination 23351 all of the Invariant Sections of all of the original documents, 23352 unmodified, and list them all as Invariant Sections of your 23353 combined work in its license notice, and that you preserve all 23354 their Warranty Disclaimers. 23355 23356 The combined work need only contain one copy of this License, and 23357 multiple identical Invariant Sections may be replaced with a single 23358 copy. If there are multiple Invariant Sections with the same name 23359 but different contents, make the title of each such section unique 23360 by adding at the end of it, in parentheses, the name of the 23361 original author or publisher of that section if known, or else a 23362 unique number. Make the same adjustment to the section titles in 23363 the list of Invariant Sections in the license notice of the 23364 combined work. 23365 23366 In the combination, you must combine any sections Entitled 23367 "History" in the various original documents, forming one section 23368 Entitled "History"; likewise combine any sections Entitled 23369 "Acknowledgements", and any sections Entitled "Dedications". You 23370 must delete all sections Entitled "Endorsements." 23371 23372 6. COLLECTIONS OF DOCUMENTS 23373 23374 You may make a collection consisting of the Document and other 23375 documents released under this License, and replace the individual 23376 copies of this License in the various documents with a single copy 23377 that is included in the collection, provided that you follow the 23378 rules of this License for verbatim copying of each of the 23379 documents in all other respects. 23380 23381 You may extract a single document from such a collection, and 23382 distribute it individually under this License, provided you insert 23383 a copy of this License into the extracted document, and follow 23384 this License in all other respects regarding verbatim copying of 23385 that document. 23386 23387 7. AGGREGATION WITH INDEPENDENT WORKS 23388 23389 A compilation of the Document or its derivatives with other 23390 separate and independent documents or works, in or on a volume of 23391 a storage or distribution medium, is called an "aggregate" if the 23392 copyright resulting from the compilation is not used to limit the 23393 legal rights of the compilation's users beyond what the individual 23394 works permit. When the Document is included an aggregate, this 23395 License does not apply to the other works in the aggregate which 23396 are not themselves derivative works of the Document. 23397 23398 If the Cover Text requirement of section 3 is applicable to these 23399 copies of the Document, then if the Document is less than one half 23400 of the entire aggregate, the Document's Cover Texts may be placed 23401 on covers that bracket the Document within the aggregate, or the 23402 electronic equivalent of covers if the Document is in electronic 23403 form. Otherwise they must appear on printed covers that bracket 23404 the whole aggregate. 23405 23406 8. TRANSLATION 23407 23408 Translation is considered a kind of modification, so you may 23409 distribute translations of the Document under the terms of section 23410 4. Replacing Invariant Sections with translations requires special 23411 permission from their copyright holders, but you may include 23412 translations of some or all Invariant Sections in addition to the 23413 original versions of these Invariant Sections. You may include a 23414 translation of this License, and all the license notices in the 23415 Document, and any Warrany Disclaimers, provided that you also 23416 include the original English version of this License and the 23417 original versions of those notices and disclaimers. In case of a 23418 disagreement between the translation and the original version of 23419 this License or a notice or disclaimer, the original version will 23420 prevail. 23421 23422 If a section in the Document is Entitled "Acknowledgements", 23423 "Dedications", or "History", the requirement (section 4) to 23424 Preserve its Title (section 1) will typically require changing the 23425 actual title. 23426 23427 9. TERMINATION 23428 23429 You may not copy, modify, sublicense, or distribute the Document 23430 except as expressly provided for under this License. Any other 23431 attempt to copy, modify, sublicense or distribute the Document is 23432 void, and will automatically terminate your rights under this 23433 License. However, parties who have received copies, or rights, 23434 from you under this License will not have their licenses 23435 terminated so long as such parties remain in full compliance. 23436 23437 10. FUTURE REVISIONS OF THIS LICENSE 23438 23439 The Free Software Foundation may publish new, revised versions of 23440 the GNU Free Documentation License from time to time. Such new 23441 versions will be similar in spirit to the present version, but may 23442 differ in detail to address new problems or concerns. See 23443 `http://www.gnu.org/copyleft/'. 23444 23445 Each version of the License is given a distinguishing version 23446 number. If the Document specifies that a particular numbered 23447 version of this License "or any later version" applies to it, you 23448 have the option of following the terms and conditions either of 23449 that specified version or of any later version that has been 23450 published (not as a draft) by the Free Software Foundation. If 23451 the Document does not specify a version number of this License, 23452 you may choose any version ever published (not as a draft) by the 23453 Free Software Foundation. 23454 23455ADDENDUM: How to use this License for your documents 23456==================================================== 23457 23458To use this License in a document you have written, include a copy of 23459the License in the document and put the following copyright and license 23460notices just after the title page: 23461 23462 Copyright (C) YEAR YOUR NAME. 23463 Permission is granted to copy, distribute and/or modify this document 23464 under the terms of the GNU Free Documentation License, Version 1.2 23465 or any later version published by the Free Software Foundation; 23466 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. 23467 A copy of the license is included in the section entitled ``GNU 23468 Free Documentation License''. 23469 23470 If you have Invariant Sections, Front-Cover Texts and Back-Cover 23471Texts, replace the "with...Texts." line with this: 23472 23473 with the Invariant Sections being LIST THEIR TITLES, with 23474 the Front-Cover Texts being LIST, and with the Back-Cover Texts 23475 being LIST. 23476 23477 If you have Invariant Sections without Cover Texts, or some other 23478combination of the three, merge those two alternatives to suit the 23479situation. 23480 23481 If your document contains nontrivial examples of program code, we 23482recommend releasing these examples in parallel under your choice of 23483free software license, such as the GNU General Public License, to 23484permit their use in free software. 23485 23486 23487File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 23488 23489Contributors to GCC 23490******************* 23491 23492The GCC project would like to thank its many contributors. Without 23493them the project would not have been nearly as successful as it has 23494been. Any omissions in this list are accidental. Feel free to contact 23495<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 23496some of your contributions are not listed. Please keep this list in 23497alphabetical order. 23498 23499 * Analog Devices helped implement the support for complex data types 23500 and iterators. 23501 23502 * John David Anglin for threading-related fixes and improvements to 23503 libstdc++-v3, and the HP-UX port. 23504 23505 * James van Artsdalen wrote the code that makes efficient use of the 23506 Intel 80387 register stack. 23507 23508 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 23509 Series port. 23510 23511 * Alasdair Baird for various bug fixes. 23512 23513 * Giovanni Bajo for analyzing lots of complicated C++ problem 23514 reports. 23515 23516 * Peter Barada for his work to improve code generation for new 23517 ColdFire cores. 23518 23519 * Gerald Baumgartner added the signature extension to the C++ front 23520 end. 23521 23522 * Godmar Back for his Java improvements and encouragement. 23523 23524 * Scott Bambrough for help porting the Java compiler. 23525 23526 * Wolfgang Bangerth for processing tons of bug reports. 23527 23528 * Jon Beniston for his Microsoft Windows port of Java. 23529 23530 * Daniel Berlin for better DWARF2 support, faster/better 23531 optimizations, improved alias analysis, plus migrating GCC to 23532 Bugzilla. 23533 23534 * Geoff Berry for his Java object serialization work and various 23535 patches. 23536 23537 * Eric Blake for helping to make GCJ and libgcj conform to the 23538 specifications. 23539 23540 * Segher Boessenkool for various fixes. 23541 23542 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 23543 other Java work. 23544 23545 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 23546 miscellaneous clean-ups. 23547 23548 * Eric Botcazou for fixing middle- and backend bugs left and right. 23549 23550 * Per Bothner for his direction via the steering committee and 23551 various improvements to the infrastructure for supporting new 23552 languages. Chill front end implementation. Initial 23553 implementations of cpplib, fix-header, config.guess, libio, and 23554 past C++ library (libg++) maintainer. Dreaming up, designing and 23555 implementing much of GCJ. 23556 23557 * Devon Bowen helped port GCC to the Tahoe. 23558 23559 * Don Bowman for mips-vxworks contributions. 23560 23561 * Dave Brolley for work on cpplib and Chill. 23562 23563 * Robert Brown implemented the support for Encore 32000 systems. 23564 23565 * Christian Bruel for improvements to local store elimination. 23566 23567 * Herman A.J. ten Brugge for various fixes. 23568 23569 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 23570 FAQ. 23571 23572 * Joe Buck for his direction via the steering committee. 23573 23574 * Craig Burley for leadership of the Fortran effort. 23575 23576 * Stephan Buys for contributing Doxygen notes for libstdc++. 23577 23578 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 23579 to the C++ strings, streambufs and formatted I/O, hard detective 23580 work on the frustrating localization issues, and keeping up with 23581 the problem reports. 23582 23583 * John Carr for his alias work, SPARC hacking, infrastructure 23584 improvements, previous contributions to the steering committee, 23585 loop optimizations, etc. 23586 23587 * Stephane Carrez for 68HC11 and 68HC12 ports. 23588 23589 * Steve Chamberlain for support for the Renesas SH and H8 processors 23590 and the PicoJava processor, and for GCJ config fixes. 23591 23592 * Glenn Chambers for help with the GCJ FAQ. 23593 23594 * John-Marc Chandonia for various libgcj patches. 23595 23596 * Scott Christley for his Objective-C contributions. 23597 23598 * Eric Christopher for his Java porting help and clean-ups. 23599 23600 * Branko Cibej for more warning contributions. 23601 23602 * The GNU Classpath project for all of their merged runtime code. 23603 23604 * Nick Clifton for arm, mcore, fr30, v850, m32r work, `--help', and 23605 other random hacking. 23606 23607 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 23608 23609 * R. Kelley Cook for making GCC buildable from a read-only directory 23610 as well as other miscellaneous build process and documentation 23611 clean-ups. 23612 23613 * Ralf Corsepius for SH testing and minor bugfixing. 23614 23615 * Stan Cox for care and feeding of the x86 port and lots of behind 23616 the scenes hacking. 23617 23618 * Alex Crain provided changes for the 3b1. 23619 23620 * Ian Dall for major improvements to the NS32k port. 23621 23622 * Paul Dale for his work to add uClinux platform support to the m68k 23623 backend. 23624 23625 * Dario Dariol contributed the four varieties of sample programs 23626 that print a copy of their source. 23627 23628 * Russell Davidson for fstream and stringstream fixes in libstdc++. 23629 23630 * Mo DeJong for GCJ and libgcj bug fixes. 23631 23632 * DJ Delorie for the DJGPP port, build and libiberty maintenance, and 23633 various bug fixes. 23634 23635 * Gabriel Dos Reis for contributions to G++, contributions and 23636 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 23637 including valarray<>, complex<>, maintaining the numerics library 23638 (including that pesky <limits> :-) and keeping up-to-date anything 23639 to do with numbers. 23640 23641 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 23642 ISO C99 support, CFG dumping support, etc., plus support of the 23643 C++ runtime libraries including for all kinds of C interface 23644 issues, contributing and maintaining complex<>, sanity checking 23645 and disbursement, configuration architecture, libio maintenance, 23646 and early math work. 23647 23648 * Zdenek Dvorak for a new loop unroller and various fixes. 23649 23650 * Richard Earnshaw for his ongoing work with the ARM. 23651 23652 * David Edelsohn for his direction via the steering committee, 23653 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 23654 loop changes, doing the entire AIX port of libstdc++ with his bare 23655 hands, and for ensuring GCC properly keeps working on AIX. 23656 23657 * Kevin Ediger for the floating point formatting of num_put::do_put 23658 in libstdc++. 23659 23660 * Phil Edwards for libstdc++ work including configuration hackery, 23661 documentation maintainer, chief breaker of the web pages, the 23662 occasional iostream bug fix, and work on shared library symbol 23663 versioning. 23664 23665 * Paul Eggert for random hacking all over GCC. 23666 23667 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 23668 configuration support for locales and fstream-related fixes. 23669 23670 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 23671 iostreams. 23672 23673 * Christian Ehrhardt for dealing with bug reports. 23674 23675 * Ben Elliston for his work to move the Objective-C runtime into its 23676 own subdirectory and for his work on autoconf. 23677 23678 * Marc Espie for OpenBSD support. 23679 23680 * Doug Evans for much of the global optimization framework, arc, 23681 m32r, and SPARC work. 23682 23683 * Christopher Faylor for his work on the Cygwin port and for caring 23684 and feeding the gcc.gnu.org box and saving its users tons of spam. 23685 23686 * Fred Fish for BeOS support and Ada fixes. 23687 23688 * Ivan Fontes Garcia for the Portugese translation of the GCJ FAQ. 23689 23690 * Peter Gerwinski for various bug fixes and the Pascal front end. 23691 23692 * Kaveh Ghazi for his direction via the steering committee, amazing 23693 work to make `-W -Wall' useful, and continuously testing GCC on a 23694 plethora of platforms. 23695 23696 * John Gilmore for a donation to the FSF earmarked improving GNU 23697 Java. 23698 23699 * Judy Goldberg for c++ contributions. 23700 23701 * Torbjorn Granlund for various fixes and the c-torture testsuite, 23702 multiply- and divide-by-constant optimization, improved long long 23703 support, improved leaf function register allocation, and his 23704 direction via the steering committee. 23705 23706 * Anthony Green for his `-Os' contributions and Java front end work. 23707 23708 * Stu Grossman for gdb hacking, allowing GCJ developers to debug 23709 Java code. 23710 23711 * Michael K. Gschwind contributed the port to the PDP-11. 23712 23713 * Ron Guilmette implemented the `protoize' and `unprotoize' tools, 23714 the support for Dwarf symbolic debugging information, and much of 23715 the support for System V Release 4. He has also worked heavily on 23716 the Intel 386 and 860 support. 23717 23718 * Bruno Haible for improvements in the runtime overhead for EH, new 23719 warnings and assorted bug fixes. 23720 23721 * Andrew Haley for his amazing Java compiler and library efforts. 23722 23723 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 23724 series 300. 23725 23726 * Michael Hayes for various thankless work he's done trying to get 23727 the c30/c40 ports functional. Lots of loop and unroll 23728 improvements and fixes. 23729 23730 * Dara Hazeghi for wading through myriads of target-specific bug 23731 reports. 23732 23733 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 23734 23735 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 23736 work, loop opts, and generally fixing lots of old problems we've 23737 ignored for years, flow rewrite and lots of further stuff, 23738 including reviewing tons of patches. 23739 23740 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 23741 various fixes. 23742 23743 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 23744 contributed the support for the Sony NEWS machine. 23745 23746 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 23747 various fixes. 23748 23749 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 23750 of testing and bug fixing, particularly of GCC configury code. 23751 23752 * Steve Holmgren for MachTen patches. 23753 23754 * Jan Hubicka for his x86 port improvements. 23755 23756 * Falk Hueffner for working on C and optimization bug reports. 23757 23758 * Bernardo Innocenti for his m68k work, including merging of 23759 ColdFire improvements and uClinux support. 23760 23761 * Christian Iseli for various bug fixes. 23762 23763 * Kamil Iskra for general m68k hacking. 23764 23765 * Lee Iverson for random fixes and MIPS testing. 23766 23767 * Andreas Jaeger for testing and benchmarking of GCC and various bug 23768 fixes. 23769 23770 * Jakub Jelinek for his SPARC work and sibling call optimizations as 23771 well as lots of bug fixes and test cases, and for improving the 23772 Java build system. 23773 23774 * Janis Johnson for ia64 testing and fixes, her quality improvement 23775 sidetracks, and web page maintenance. 23776 23777 * Kean Johnston for SCO OpenServer support and various fixes. 23778 23779 * Tim Josling for the sample language treelang based originally on 23780 Richard Kenner's ""toy" language". 23781 23782 * Nicolai Josuttis for additional libstdc++ documentation. 23783 23784 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 23785 target. 23786 23787 * David Kashtan of SRI adapted GCC to VMS. 23788 23789 * Ryszard Kabatek for many, many libstdc++ bug fixes and 23790 optimizations of strings, especially member functions, and for 23791 auto_ptr fixes. 23792 23793 * Geoffrey Keating for his ongoing work to make the PPC work for 23794 GNU/Linux and his automatic regression tester. 23795 23796 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 23797 work in just about every part of libstdc++. 23798 23799 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 23800 MIL-STD-1750A. 23801 23802 * Richard Kenner of the New York University Ultracomputer Research 23803 Laboratory wrote the machine descriptions for the AMD 29000, the 23804 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 23805 support for instruction attributes. He also made changes to 23806 better support RISC processors including changes to common 23807 subexpression elimination, strength reduction, function calling 23808 sequence handling, and condition code support, in addition to 23809 generalizing the code for frame pointer elimination and delay slot 23810 scheduling. Richard Kenner was also the head maintainer of GCC 23811 for several years. 23812 23813 * Mumit Khan for various contributions to the Cygwin and Mingw32 23814 ports and maintaining binary releases for Microsoft Windows hosts, 23815 and for massive libstdc++ porting work to Cygwin/Mingw32. 23816 23817 * Robin Kirkham for cpu32 support. 23818 23819 * Mark Klein for PA improvements. 23820 23821 * Thomas Koenig for various bug fixes. 23822 23823 * Bruce Korb for the new and improved fixincludes code. 23824 23825 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 23826 effort. 23827 23828 * Charles LaBrec contributed the support for the Integrated Solutions 23829 68020 system. 23830 23831 * Jeff Law for his direction via the steering committee, 23832 coordinating the entire egcs project and GCC 2.95, rolling out 23833 snapshots and releases, handling merges from GCC2, reviewing tons 23834 of patches that might have fallen through the cracks else, and 23835 random but extensive hacking. 23836 23837 * Marc Lehmann for his direction via the steering committee and 23838 helping with analysis and improvements of x86 performance. 23839 23840 * Ted Lemon wrote parts of the RTL reader and printer. 23841 23842 * Kriang Lerdsuwanakij for C++ improvements including template as 23843 template parameter support, and many C++ fixes. 23844 23845 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 23846 and random work on the Java front end. 23847 23848 * Alain Lichnewsky ported GCC to the MIPS CPU. 23849 23850 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 23851 and patches. 23852 23853 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 23854 23855 * Weiwen Liu for testing and various bug fixes. 23856 23857 * Dave Love for his ongoing work with the Fortran front end and 23858 runtime libraries. 23859 23860 * Martin von Lo"wis for internal consistency checking infrastructure, 23861 various C++ improvements including namespace support, and tons of 23862 assistance with libstdc++/compiler merges. 23863 23864 * H.J. Lu for his previous contributions to the steering committee, 23865 many x86 bug reports, prototype patches, and keeping the GNU/Linux 23866 ports working. 23867 23868 * Greg McGary for random fixes and (someday) bounded pointers. 23869 23870 * Andrew MacLeod for his ongoing work in building a real EH system, 23871 various code generation improvements, work on the global 23872 optimizer, etc. 23873 23874 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 23875 hacking improvements to compile-time performance, overall 23876 knowledge and direction in the area of instruction scheduling, and 23877 design and implementation of the automaton based instruction 23878 scheduler. 23879 23880 * Bob Manson for his behind the scenes work on dejagnu. 23881 23882 * Philip Martin for lots of libstdc++ string and vector iterator 23883 fixes and improvements, and string clean up and testsuites. 23884 23885 * All of the Mauve project contributors, for Java test code. 23886 23887 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 23888 23889 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 23890 23891 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 23892 powerpc, haifa, ECOFF debug support, and other assorted hacking. 23893 23894 * Jason Merrill for his direction via the steering committee and 23895 leading the G++ effort. 23896 23897 * David Miller for his direction via the steering committee, lots of 23898 SPARC work, improvements in jump.c and interfacing with the Linux 23899 kernel developers. 23900 23901 * Gary Miller ported GCC to Charles River Data Systems machines. 23902 23903 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 23904 the entire libstdc++ testsuite namespace-compatible. 23905 23906 * Mark Mitchell for his direction via the steering committee, 23907 mountains of C++ work, load/store hoisting out of loops, alias 23908 analysis improvements, ISO C `restrict' support, and serving as 23909 release manager for GCC 3.x. 23910 23911 * Alan Modra for various GNU/Linux bits and testing. 23912 23913 * Toon Moene for his direction via the steering committee, Fortran 23914 maintenance, and his ongoing work to make us make Fortran run fast. 23915 23916 * Jason Molenda for major help in the care and feeding of all the 23917 services on the gcc.gnu.org (formerly egcs.cygnus.com) 23918 machine--mail, web services, ftp services, etc etc. Doing all 23919 this work on scrap paper and the backs of envelopes would have 23920 been... difficult. 23921 23922 * Catherine Moore for fixing various ugly problems we have sent her 23923 way, including the haifa bug which was killing the Alpha & PowerPC 23924 Linux kernels. 23925 23926 * Mike Moreton for his various Java patches. 23927 23928 * David Mosberger-Tang for various Alpha improvements, and for the 23929 initial IA-64 port. 23930 23931 * Stephen Moshier contributed the floating point emulator that 23932 assists in cross-compilation and permits support for floating 23933 point numbers wider than 64 bits and for ISO C99 support. 23934 23935 * Bill Moyer for his behind the scenes work on various issues. 23936 23937 * Philippe De Muyter for his work on the m68k port. 23938 23939 * Joseph S. Myers for his work on the PDP-11 port, format checking 23940 and ISO C99 support, and continuous emphasis on (and contributions 23941 to) documentation. 23942 23943 * Nathan Myers for his work on libstdc++-v3: architecture and 23944 authorship through the first three snapshots, including 23945 implementation of locale infrastructure, string, shadow C headers, 23946 and the initial project documentation (DESIGN, CHECKLIST, and so 23947 forth). Later, more work on MT-safe string and shadow headers. 23948 23949 * Felix Natter for documentation on porting libstdc++. 23950 23951 * Nathanael Nerode for cleaning up the configuration/build process. 23952 23953 * NeXT, Inc. donated the front end that supports the Objective-C 23954 language. 23955 23956 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to 23957 the search engine setup, various documentation fixes and other 23958 small fixes. 23959 23960 * Geoff Noer for this work on getting cygwin native builds working. 23961 23962 * Diego Novillo for his SPEC performance tracking web pages and 23963 assorted fixes in the middle end and various back ends. 23964 23965 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 23966 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and 23967 related infrastructure improvements. 23968 23969 * Alexandre Oliva for various build infrastructure improvements, 23970 scripts and amazing testing work, including keeping libtool issues 23971 sane and happy. 23972 23973 * Melissa O'Neill for various NeXT fixes. 23974 23975 * Rainer Orth for random MIPS work, including improvements to GCC's 23976 o32 ABI support, improvements to dejagnu's MIPS support, Java 23977 configuration clean-ups and porting work, etc. 23978 23979 * Hartmut Penner for work on the s390 port. 23980 23981 * Paul Petersen wrote the machine description for the Alliant FX/8. 23982 23983 * Alexandre Petit-Bianco for implementing much of the Java compiler 23984 and continued Java maintainership. 23985 23986 * Matthias Pfaller for major improvements to the NS32k port. 23987 23988 * Gerald Pfeifer for his direction via the steering committee, 23989 pointing out lots of problems we need to solve, maintenance of the 23990 web pages, and taking care of documentation maintenance in general. 23991 23992 * Andrew Pinski for processing bug reports by the dozen. 23993 23994 * Ovidiu Predescu for his work on the Objective-C front end and 23995 runtime libraries. 23996 23997 * Jerry Quinn for major performance improvements in C++ formatted 23998 I/O. 23999 24000 * Ken Raeburn for various improvements to checker, MIPS ports and 24001 various cleanups in the compiler. 24002 24003 * Rolf W. Rasmussen for hacking on AWT. 24004 24005 * David Reese of Sun Microsystems contributed to the Solaris on 24006 PowerPC port. 24007 24008 * Volker Reichelt for keeping up with the problem reports. 24009 24010 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 24011 hacking. 24012 24013 * Loren J. Rittle for improvements to libstdc++-v3 including the 24014 FreeBSD port, threading fixes, thread-related configury changes, 24015 critical threading documentation, and solutions to really tricky 24016 I/O problems, as well as keeping GCC properly working on FreeBSD 24017 and continuous testing. 24018 24019 * Craig Rodrigues for processing tons of bug reports. 24020 24021 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 24022 24023 * Ken Rose for fixes to GCC's delay slot filling code. 24024 24025 * Paul Rubin wrote most of the preprocessor. 24026 24027 * Pe'tur Runo'lfsson for major performance improvements in C++ 24028 formatted I/O and large file support in C++ filebuf. 24029 24030 * Chip Salzenberg for libstdc++ patches and improvements to locales, 24031 traits, Makefiles, libio, libtool hackery, and "long long" support. 24032 24033 * Juha Sarlin for improvements to the H8 code generator. 24034 24035 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 24036 300. 24037 24038 * Roger Sayle for improvements to constant folding and GCC's RTL 24039 optimizers as well as for fixing numerous bugs. 24040 24041 * Bradley Schatz for his work on the GCJ FAQ. 24042 24043 * Peter Schauer wrote the code to allow debugging to work on the 24044 Alpha. 24045 24046 * William Schelter did most of the work on the Intel 80386 support. 24047 24048 * Bernd Schmidt for various code generation improvements and major 24049 work in the reload pass as well a serving as release manager for 24050 GCC 2.95.3. 24051 24052 * Peter Schmid for constant testing of libstdc++ - especially 24053 application testing, going above and beyond what was requested for 24054 the release criteria - and libstdc++ header file tweaks. 24055 24056 * Jason Schroeder for jcf-dump patches. 24057 24058 * Andreas Schwab for his work on the m68k port. 24059 24060 * Joel Sherrill for his direction via the steering committee, RTEMS 24061 contributions and RTEMS testing. 24062 24063 * Nathan Sidwell for many C++ fixes/improvements. 24064 24065 * Jeffrey Siegal for helping RMS with the original design of GCC, 24066 some code which handles the parse tree and RTL data structures, 24067 constant folding and help with the original VAX & m68k ports. 24068 24069 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 24070 from the LWG (thereby keeping GCC in line with updates from the 24071 ISO). 24072 24073 * Franz Sirl for his ongoing work with making the PPC port stable 24074 for GNU/Linux. 24075 24076 * Andrey Slepuhin for assorted AIX hacking. 24077 24078 * Christopher Smith did the port for Convex machines. 24079 24080 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 24081 24082 * Randy Smith finished the Sun FPA support. 24083 24084 * Scott Snyder for queue, iterator, istream, and string fixes and 24085 libstdc++ testsuite entries. 24086 24087 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 24088 24089 * Richard Stallman, for writing the original GCC and launching the 24090 GNU project. 24091 24092 * Jan Stein of the Chalmers Computer Society provided support for 24093 Genix, as well as part of the 32000 machine description. 24094 24095 * Nigel Stephens for various mips16 related fixes/improvements. 24096 24097 * Jonathan Stone wrote the machine description for the Pyramid 24098 computer. 24099 24100 * Graham Stott for various infrastructure improvements. 24101 24102 * John Stracke for his Java HTTP protocol fixes. 24103 24104 * Mike Stump for his Elxsi port, G++ contributions over the years 24105 and more recently his vxworks contributions 24106 24107 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 24108 24109 * Shigeya Suzuki for this fixes for the bsdi platforms. 24110 24111 * Ian Lance Taylor for his mips16 work, general configury hacking, 24112 fixincludes, etc. 24113 24114 * Holger Teutsch provided the support for the Clipper CPU. 24115 24116 * Gary Thomas for his ongoing work to make the PPC work for 24117 GNU/Linux. 24118 24119 * Philipp Thomas for random bug fixes throughout the compiler 24120 24121 * Jason Thorpe for thread support in libstdc++ on NetBSD. 24122 24123 * Kresten Krab Thorup wrote the run time support for the Objective-C 24124 language and the fantastic Java bytecode interpreter. 24125 24126 * Michael Tiemann for random bug fixes, the first instruction 24127 scheduler, initial C++ support, function integration, NS32k, SPARC 24128 and M88k machine description work, delay slot scheduling. 24129 24130 * Andreas Tobler for his work porting libgcj to Darwin. 24131 24132 * Teemu Torma for thread safe exception handling support. 24133 24134 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 24135 definitions, and of the VAX machine description. 24136 24137 * Tom Tromey for internationalization support and for his many Java 24138 contributions and libgcj maintainership. 24139 24140 * Lassi Tuura for improvements to config.guess to determine HP 24141 processor types. 24142 24143 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 24144 24145 * Brent Verner for work with the libstdc++ cshadow files and their 24146 associated configure steps. 24147 24148 * Todd Vierling for contributions for NetBSD ports. 24149 24150 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 24151 guidance. 24152 24153 * Dean Wakerley for converting the install documentation from HTML 24154 to texinfo in time for GCC 3.0. 24155 24156 * Krister Walfridsson for random bug fixes. 24157 24158 * Stephen M. Webb for time and effort on making libstdc++ shadow 24159 files work with the tricky Solaris 8+ headers, and for pushing the 24160 build-time header tree. 24161 24162 * John Wehle for various improvements for the x86 code generator, 24163 related infrastructure improvements to help x86 code generation, 24164 value range propagation and other work, WE32k port. 24165 24166 * Ulrich Weigand for work on the s390 port. 24167 24168 * Zack Weinberg for major work on cpplib and various other bug fixes. 24169 24170 * Matt Welsh for help with Linux Threads support in GCJ. 24171 24172 * Urban Widmark for help fixing java.io. 24173 24174 * Mark Wielaard for new Java library code and his work integrating 24175 with Classpath. 24176 24177 * Dale Wiles helped port GCC to the Tahoe. 24178 24179 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 24180 24181 * Jim Wilson for his direction via the steering committee, tackling 24182 hard problems in various places that nobody else wanted to work 24183 on, strength reduction and other loop optimizations. 24184 24185 * Carlo Wood for various fixes. 24186 24187 * Tom Wood for work on the m88k port. 24188 24189 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 24190 description for the Tron architecture (specifically, the Gmicro). 24191 24192 * Kevin Zachmann helped ported GCC to the Tahoe. 24193 24194 * Gilles Zunino for help porting Java to Irix. 24195 24196 24197 In addition to the above, all of which also contributed time and 24198energy in testing GCC, we would like to thank the following for their 24199contributions to testing: 24200 24201 * Michael Abd-El-Malek 24202 24203 * Thomas Arend 24204 24205 * Bonzo Armstrong 24206 24207 * Steven Ashe 24208 24209 * Chris Baldwin 24210 24211 * David Billinghurst 24212 24213 * Jim Blandy 24214 24215 * Stephane Bortzmeyer 24216 24217 * Horst von Brand 24218 24219 * Frank Braun 24220 24221 * Rodney Brown 24222 24223 * Sidney Cadot 24224 24225 * Bradford Castalia 24226 24227 * Ralph Doncaster 24228 24229 * Richard Emberson 24230 24231 * Levente Farkas 24232 24233 * Graham Fawcett 24234 24235 * Robert A. French 24236 24237 * Jo"rgen Freyh 24238 24239 * Mark K. Gardner 24240 24241 * Charles-Antoine Gauthier 24242 24243 * Yung Shing Gene 24244 24245 * David Gilbert 24246 24247 * Simon Gornall 24248 24249 * Fred Gray 24250 24251 * John Griffin 24252 24253 * Patrik Hagglund 24254 24255 * Phil Hargett 24256 24257 * Amancio Hasty 24258 24259 * Bryan W. Headley 24260 24261 * Kevin B. Hendricks 24262 24263 * Joep Jansen 24264 24265 * Christian Joensson 24266 24267 * David Kidd 24268 24269 * Tobias Kuipers 24270 24271 * Anand Krishnaswamy 24272 24273 * llewelly 24274 24275 * Damon Love 24276 24277 * Brad Lucier 24278 24279 * Matthias Klose 24280 24281 * Martin Knoblauch 24282 24283 * Jesse Macnish 24284 24285 * Stefan Morrell 24286 24287 * Anon A. Mous 24288 24289 * Matthias Mueller 24290 24291 * Pekka Nikander 24292 24293 * Jon Olson 24294 24295 * Magnus Persson 24296 24297 * Chris Pollard 24298 24299 * Richard Polton 24300 24301 * David Rees 24302 24303 * Paul Reilly 24304 24305 * Tom Reilly 24306 24307 * Torsten Rueger 24308 24309 * Danny Sadinoff 24310 24311 * Marc Schifer 24312 24313 * David Schuler 24314 24315 * Vin Shelton 24316 24317 * Tim Souder 24318 24319 * Adam Sulmicki 24320 24321 * George Talbot 24322 24323 * Gregory Warnes 24324 24325 * David E. Young 24326 24327 * And many others 24328 24329 And finally we'd like to thank everyone who uses the compiler, 24330submits bug reports and generally reminds us why we're doing this work 24331in the first place. 24332 24333 24334File: gccint.info, Node: Option Index, Next: Index, Prev: Contributors, Up: Top 24335 24336Option Index 24337************ 24338 24339GCC's command line options are indexed here without any initial `-' or 24340`--'. Where an option has both positive and negative forms (such as 24341`-fOPTION' and `-fno-OPTION'), relevant entries in the manual are 24342indexed under the most appropriate form; it may sometimes be useful to 24343look up both forms. 24344 24345�[index�] 24346* Menu: 24347 24348* dB: Passes. (line 380) 24349* dc: Passes. (line 273) 24350* dd: Passes. (line 389) 24351* dE: Passes. (line 282) 24352* df: Passes. (line 261) 24353* dg: Passes. (line 361) 24354* dG: Passes. (line 200) 24355* di: Passes. (line 135) 24356* dj: Passes. (line 157) 24357* dk: Passes. (line 405) 24358* dl: Passes. (line 328) 24359* dL: Passes. (line 219) 24360* dN: Passes. (line 292) 24361* dR: Passes. (line 368) 24362* dr: Passes. (line 124) 24363* dS: Passes. (line 308) 24364* ds: Passes. (line 177) 24365* dt: Passes. (line 247) 24366* dZ: Passes. (line 238) 24367* fnew-ra: Passes. (line 336) 24368* frerun-cse-after-loop: Passes. (line 242) 24369* fthread-jumps: Passes. (line 165) 24370* msoft-float: Soft float library routines. 24371 (line 6) 24372 24373 24374File: gccint.info, Node: Index, Prev: Option Index, Up: Top 24375 24376Index 24377***** 24378 24379�[index�] 24380* Menu: 24381 24382* ! in constraint: Multi-Alternative. (line 47) 24383* # in constraint: Modifiers. (line 62) 24384* # in template: Output Template. (line 67) 24385* #pragma: Misc. (line 331) 24386* % in constraint: Modifiers. (line 45) 24387* % in GTY option: GTY Options. (line 24) 24388* % in template: Output Template. (line 6) 24389* & in constraint: Modifiers. (line 25) 24390* (nil): RTL Objects. (line 73) 24391* * <1>: Host Common. (line 16) 24392* *: PCH Target. (line 7) 24393* * in constraint: Modifiers. (line 67) 24394* * in template: Output Statement. (line 29) 24395* + in constraint: Modifiers. (line 12) 24396* /c in RTL dump: Flags. (line 241) 24397* /f in RTL dump: Flags. (line 246) 24398* /i in RTL dump: Flags. (line 297) 24399* /j in RTL dump: Flags. (line 310) 24400* /s in RTL dump: Flags. (line 261) 24401* /u in RTL dump: Flags. (line 320) 24402* /v in RTL dump: Flags. (line 352) 24403* 0 in constraint: Simple Constraints. (line 118) 24404* < in constraint: Simple Constraints. (line 46) 24405* = in constraint: Modifiers. (line 8) 24406* > in constraint: Simple Constraints. (line 50) 24407* ? in constraint: Multi-Alternative. (line 41) 24408* \: Output Template. (line 47) 24409* __absvdi2: Integer library routines. 24410 (line 107) 24411* __absvsi2: Integer library routines. 24412 (line 106) 24413* __adddf3: Soft float library routines. 24414 (line 23) 24415* __addsf3: Soft float library routines. 24416 (line 22) 24417* __addtf3: Soft float library routines. 24418 (line 25) 24419* __addvdi3: Integer library routines. 24420 (line 111) 24421* __addvsi3: Integer library routines. 24422 (line 110) 24423* __addxf3: Soft float library routines. 24424 (line 27) 24425* __ashldi3: Integer library routines. 24426 (line 14) 24427* __ashlsi3: Integer library routines. 24428 (line 13) 24429* __ashlti3: Integer library routines. 24430 (line 15) 24431* __ashrdi3: Integer library routines. 24432 (line 19) 24433* __ashrsi3: Integer library routines. 24434 (line 18) 24435* __ashrti3: Integer library routines. 24436 (line 20) 24437* __builtin_args_info: Varargs. (line 42) 24438* __builtin_classify_type: Varargs. (line 76) 24439* __builtin_next_arg: Varargs. (line 66) 24440* __builtin_saveregs: Varargs. (line 24) 24441* __clear_cache: Miscellaneous routines. 24442 (line 10) 24443* __clzdi2: Integer library routines. 24444 (line 131) 24445* __clzsi2: Integer library routines. 24446 (line 130) 24447* __clzti2: Integer library routines. 24448 (line 132) 24449* __cmpdf2: Soft float library routines. 24450 (line 145) 24451* __cmpdi2: Integer library routines. 24452 (line 87) 24453* __cmpsf2: Soft float library routines. 24454 (line 144) 24455* __cmptf2: Soft float library routines. 24456 (line 146) 24457* __cmpti2: Integer library routines. 24458 (line 88) 24459* __CTOR_LIST__: Initialization. (line 25) 24460* __ctzdi2: Integer library routines. 24461 (line 138) 24462* __ctzsi2: Integer library routines. 24463 (line 137) 24464* __ctzti2: Integer library routines. 24465 (line 139) 24466* __divdf3: Soft float library routines. 24467 (line 48) 24468* __divdi3: Integer library routines. 24469 (line 25) 24470* __divsf3: Soft float library routines. 24471 (line 47) 24472* __divsi3: Integer library routines. 24473 (line 24) 24474* __divtf3: Soft float library routines. 24475 (line 50) 24476* __divti3: Integer library routines. 24477 (line 26) 24478* __divxf3: Soft float library routines. 24479 (line 52) 24480* __DTOR_LIST__: Initialization. (line 25) 24481* __eqdf2: Soft float library routines. 24482 (line 175) 24483* __eqsf2: Soft float library routines. 24484 (line 174) 24485* __eqtf2: Soft float library routines. 24486 (line 176) 24487* __extenddftf2: Soft float library routines. 24488 (line 68) 24489* __extenddfxf2: Soft float library routines. 24490 (line 69) 24491* __extendsfdf2: Soft float library routines. 24492 (line 65) 24493* __extendsftf2: Soft float library routines. 24494 (line 66) 24495* __extendsfxf2: Soft float library routines. 24496 (line 67) 24497* __ffsdi2: Integer library routines. 24498 (line 144) 24499* __ffsti2: Integer library routines. 24500 (line 145) 24501* __fixdfdi: Soft float library routines. 24502 (line 88) 24503* __fixdfsi: Soft float library routines. 24504 (line 81) 24505* __fixdfti: Soft float library routines. 24506 (line 94) 24507* __fixsfdi: Soft float library routines. 24508 (line 87) 24509* __fixsfsi: Soft float library routines. 24510 (line 80) 24511* __fixsfti: Soft float library routines. 24512 (line 93) 24513* __fixtfdi: Soft float library routines. 24514 (line 89) 24515* __fixtfsi: Soft float library routines. 24516 (line 82) 24517* __fixtfti: Soft float library routines. 24518 (line 95) 24519* __fixunsdfdi: Soft float library routines. 24520 (line 108) 24521* __fixunsdfsi: Soft float library routines. 24522 (line 101) 24523* __fixunsdfti: Soft float library routines. 24524 (line 115) 24525* __fixunssfdi: Soft float library routines. 24526 (line 107) 24527* __fixunssfsi: Soft float library routines. 24528 (line 100) 24529* __fixunssfti: Soft float library routines. 24530 (line 114) 24531* __fixunstfdi: Soft float library routines. 24532 (line 109) 24533* __fixunstfsi: Soft float library routines. 24534 (line 102) 24535* __fixunstfti: Soft float library routines. 24536 (line 116) 24537* __fixunsxfdi: Soft float library routines. 24538 (line 110) 24539* __fixunsxfsi: Soft float library routines. 24540 (line 103) 24541* __fixunsxfti: Soft float library routines. 24542 (line 117) 24543* __fixxfdi: Soft float library routines. 24544 (line 90) 24545* __fixxfsi: Soft float library routines. 24546 (line 83) 24547* __fixxfti: Soft float library routines. 24548 (line 96) 24549* __floatdidf: Soft float library routines. 24550 (line 128) 24551* __floatdisf: Soft float library routines. 24552 (line 127) 24553* __floatditf: Soft float library routines. 24554 (line 129) 24555* __floatdixf: Soft float library routines. 24556 (line 130) 24557* __floatsidf: Soft float library routines. 24558 (line 122) 24559* __floatsisf: Soft float library routines. 24560 (line 121) 24561* __floatsitf: Soft float library routines. 24562 (line 123) 24563* __floatsixf: Soft float library routines. 24564 (line 124) 24565* __floattidf: Soft float library routines. 24566 (line 134) 24567* __floattisf: Soft float library routines. 24568 (line 133) 24569* __floattitf: Soft float library routines. 24570 (line 135) 24571* __floattixf: Soft float library routines. 24572 (line 136) 24573* __gedf2: Soft float library routines. 24574 (line 187) 24575* __gesf2: Soft float library routines. 24576 (line 186) 24577* __getf2: Soft float library routines. 24578 (line 188) 24579* __gtdf2: Soft float library routines. 24580 (line 205) 24581* __gtsf2: Soft float library routines. 24582 (line 204) 24583* __gttf2: Soft float library routines. 24584 (line 206) 24585* __ledf2: Soft float library routines. 24586 (line 199) 24587* __lesf2: Soft float library routines. 24588 (line 198) 24589* __letf2: Soft float library routines. 24590 (line 200) 24591* __lshrdi3: Integer library routines. 24592 (line 31) 24593* __lshrsi3: Integer library routines. 24594 (line 30) 24595* __lshrti3: Integer library routines. 24596 (line 32) 24597* __ltdf2: Soft float library routines. 24598 (line 193) 24599* __ltsf2: Soft float library routines. 24600 (line 192) 24601* __lttf2: Soft float library routines. 24602 (line 194) 24603* __main: Collect2. (line 15) 24604* __moddi3: Integer library routines. 24605 (line 37) 24606* __modsi3: Integer library routines. 24607 (line 36) 24608* __modti3: Integer library routines. 24609 (line 38) 24610* __muldf3: Soft float library routines. 24611 (line 40) 24612* __muldi3: Integer library routines. 24613 (line 43) 24614* __mulsf3: Soft float library routines. 24615 (line 39) 24616* __mulsi3: Integer library routines. 24617 (line 42) 24618* __multf3: Soft float library routines. 24619 (line 42) 24620* __multi3: Integer library routines. 24621 (line 44) 24622* __mulvdi3: Integer library routines. 24623 (line 115) 24624* __mulvsi3: Integer library routines. 24625 (line 114) 24626* __mulxf3: Soft float library routines. 24627 (line 44) 24628* __nedf2: Soft float library routines. 24629 (line 181) 24630* __negdf2: Soft float library routines. 24631 (line 56) 24632* __negdi2: Integer library routines. 24633 (line 47) 24634* __negsf2: Soft float library routines. 24635 (line 55) 24636* __negtf2: Soft float library routines. 24637 (line 57) 24638* __negti2: Integer library routines. 24639 (line 48) 24640* __negvdi2: Integer library routines. 24641 (line 119) 24642* __negvsi2: Integer library routines. 24643 (line 118) 24644* __negxf2: Soft float library routines. 24645 (line 58) 24646* __nesf2: Soft float library routines. 24647 (line 180) 24648* __netf2: Soft float library routines. 24649 (line 182) 24650* __paritydi2: Integer library routines. 24651 (line 151) 24652* __paritysi2: Integer library routines. 24653 (line 150) 24654* __parityti2: Integer library routines. 24655 (line 152) 24656* __popcountdi2: Integer library routines. 24657 (line 157) 24658* __popcountsi2: Integer library routines. 24659 (line 156) 24660* __popcountti2: Integer library routines. 24661 (line 158) 24662* __subdf3: Soft float library routines. 24663 (line 31) 24664* __subsf3: Soft float library routines. 24665 (line 30) 24666* __subtf3: Soft float library routines. 24667 (line 33) 24668* __subvdi3: Integer library routines. 24669 (line 123) 24670* __subvsi3: Integer library routines. 24671 (line 122) 24672* __subxf3: Soft float library routines. 24673 (line 35) 24674* __truncdfsf2: Soft float library routines. 24675 (line 76) 24676* __trunctfdf2: Soft float library routines. 24677 (line 73) 24678* __trunctfsf2: Soft float library routines. 24679 (line 75) 24680* __truncxfdf2: Soft float library routines. 24681 (line 72) 24682* __truncxfsf2: Soft float library routines. 24683 (line 74) 24684* __ucmpdi2: Integer library routines. 24685 (line 93) 24686* __ucmpti2: Integer library routines. 24687 (line 95) 24688* __udivdi3: Integer library routines. 24689 (line 54) 24690* __udivmoddi3: Integer library routines. 24691 (line 61) 24692* __udivsi3: Integer library routines. 24693 (line 52) 24694* __udivti3: Integer library routines. 24695 (line 56) 24696* __umoddi3: Integer library routines. 24697 (line 71) 24698* __umodsi3: Integer library routines. 24699 (line 69) 24700* __umodti3: Integer library routines. 24701 (line 73) 24702* __unorddf2: Soft float library routines. 24703 (line 154) 24704* __unordsf2: Soft float library routines. 24705 (line 153) 24706* __unordtf2: Soft float library routines. 24707 (line 155) 24708* abort: Portability. (line 21) 24709* abs: Arithmetic. (line 165) 24710* abs and attributes: Expressions. (line 64) 24711* ABS_EXPR: Expression trees. (line 6) 24712* absence_set: Automaton pipeline description. 24713 (line 172) 24714* absM2 instruction pattern: Standard Names. (line 231) 24715* absolute value: Arithmetic. (line 165) 24716* access to operands: Accessors. (line 6) 24717* access to special operands: Special Accessors. (line 6) 24718* accessors: Accessors. (line 6) 24719* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 46) 24720* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135) 24721* ADA_LONG_TYPE_SIZE: Type Layout. (line 26) 24722* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15) 24723* addM3 instruction pattern: Standard Names. (line 161) 24724* addMODEcc instruction pattern: Standard Names. (line 546) 24725* addr_diff_vec: Side Effects. (line 295) 24726* addr_diff_vec, length of: Insn Lengths. (line 26) 24727* ADDR_EXPR: Expression trees. (line 6) 24728* addr_vec: Side Effects. (line 290) 24729* addr_vec, length of: Insn Lengths. (line 26) 24730* address constraints: Simple Constraints. (line 152) 24731* address_operand: Simple Constraints. (line 156) 24732* addressing modes: Addressing Modes. (line 6) 24733* addressof: Regs and Memory. (line 260) 24734* ADJUST_FIELD_ALIGN: Storage Layout. (line 186) 24735* ADJUST_INSN_LENGTH: Insn Lengths. (line 35) 24736* aggregates as return values: Aggregate Return. (line 6) 24737* ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32) 24738* ALL_REGS: Register Classes. (line 17) 24739* ALLOCATE_INITIAL_VALUE: Misc. (line 607) 24740* allocate_stack instruction pattern: Standard Names. (line 868) 24741* alternate entry points: Insns. (line 146) 24742* analysis, data flow: Passes. (line 251) 24743* and: Arithmetic. (line 132) 24744* and and attributes: Expressions. (line 50) 24745* and, canonicalization of: Insn Canonicalizations. 24746 (line 48) 24747* andM3 instruction pattern: Standard Names. (line 167) 24748* APPLY_RESULT_SIZE: Scalar Return. (line 85) 24749* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 154) 24750* ARG_POINTER_REGNUM: Frame Registers. (line 41) 24751* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 24752* arg_pointer_rtx: Frame Registers. (line 85) 24753* ARGS_GROW_DOWNWARD: Frame Layout. (line 35) 24754* argument passing: Interface. (line 36) 24755* arguments in registers: Register Arguments. (line 6) 24756* arguments on stack: Stack Arguments. (line 6) 24757* arithmetic library: Soft float library routines. 24758 (line 6) 24759* arithmetic shift: Arithmetic. (line 147) 24760* arithmetic simplifications: Passes. (line 79) 24761* arithmetic, in RTL: Arithmetic. (line 6) 24762* ARITHMETIC_TYPE_P: Types. (line 77) 24763* array: Types. (line 6) 24764* ARRAY_REF: Expression trees. (line 6) 24765* ARRAY_TYPE: Types. (line 6) 24766* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 151) 24767* ashift: Arithmetic. (line 147) 24768* ashift and attributes: Expressions. (line 64) 24769* ashiftrt: Arithmetic. (line 155) 24770* ashiftrt and attributes: Expressions. (line 64) 24771* ashlM3 instruction pattern: Standard Names. (line 217) 24772* ashrM3 instruction pattern: Standard Names. (line 224) 24773* ASM_APP_OFF: File Framework. (line 61) 24774* ASM_APP_ON: File Framework. (line 54) 24775* ASM_CLOBBERS: Function Bodies. (line 6) 24776* ASM_COMMENT_START: File Framework. (line 49) 24777* ASM_CV_QUAL: Function Bodies. (line 6) 24778* ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 384) 24779* ASM_DECLARE_CONSTANT_NAME: Label Output. (line 122) 24780* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 81) 24781* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 95) 24782* ASM_DECLARE_OBJECT_NAME: Label Output. (line 108) 24783* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 137) 24784* ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 390) 24785* ASM_FINAL_SPEC: Driver. (line 144) 24786* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 145) 24787* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 310) 24788* asm_fprintf: Instruction Output. (line 123) 24789* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 134) 24790* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 294) 24791* asm_input: Side Effects. (line 277) 24792* asm_input and /v: Flags. (line 88) 24793* ASM_INPUTS: Function Bodies. (line 6) 24794* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82) 24795* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 72) 24796* asm_noperands: Insns. (line 276) 24797* asm_operands and /v: Flags. (line 88) 24798* asm_operands, RTL sharing: Sharing. (line 45) 24799* asm_operands, usage: Assembler. (line 6) 24800* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9) 24801* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26) 24802* ASM_OUTPUT_ALIGN: Alignment Output. (line 79) 24803* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 84) 24804* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 64) 24805* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 23) 24806* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 31) 24807* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 100) 24808* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 92) 24809* ASM_OUTPUT_ASCII: Data Output. (line 50) 24810* ASM_OUTPUT_BSS: Uninitialized Data. (line 44) 24811* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51) 24812* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38) 24813* ASM_OUTPUT_COMMON: Uninitialized Data. (line 10) 24814* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 282) 24815* ASM_OUTPUT_DEF: Label Output. (line 331) 24816* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 339) 24817* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 42) 24818* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 46) 24819* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 51) 24820* ASM_OUTPUT_EXTERNAL: Label Output. (line 225) 24821* ASM_OUTPUT_FDESC: Data Output. (line 59) 24822* ASM_OUTPUT_IDENT: File Framework. (line 93) 24823* ASM_OUTPUT_LABEL: Label Output. (line 9) 24824* ASM_OUTPUT_LABEL_REF: Label Output. (line 255) 24825* ASM_OUTPUT_LABELREF: Label Output. (line 241) 24826* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 79) 24827* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 88) 24828* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 35) 24829* ASM_OUTPUT_OPCODE: Instruction Output. (line 21) 24830* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 109) 24831* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 72) 24832* ASM_OUTPUT_REG_POP: Instruction Output. (line 178) 24833* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 173) 24834* ASM_OUTPUT_SHARED_BSS: Uninitialized Data. (line 74) 24835* ASM_OUTPUT_SHARED_COMMON: Uninitialized Data. (line 39) 24836* ASM_OUTPUT_SHARED_LOCAL: Uninitialized Data. (line 108) 24837* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 29) 24838* ASM_OUTPUT_SKIP: Alignment Output. (line 66) 24839* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 68) 24840* ASM_OUTPUT_SOURCE_LINE: File Framework. (line 83) 24841* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 84) 24842* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 248) 24843* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 71) 24844* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 349) 24845* ASM_OUTPUTS: Function Bodies. (line 6) 24846* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67) 24847* ASM_SPEC: Driver. (line 136) 24848* ASM_STABD_OP: DBX Options. (line 36) 24849* ASM_STABN_OP: DBX Options. (line 43) 24850* ASM_STABS_OP: DBX Options. (line 29) 24851* ASM_STMT: Function Bodies. (line 6) 24852* ASM_STRING: Function Bodies. (line 6) 24853* ASM_WEAKEN_DECL: Label Output. (line 180) 24854* ASM_WEAKEN_LABEL: Label Output. (line 167) 24855* assemble_name: Label Output. (line 8) 24856* assembler format: File Framework. (line 6) 24857* assembler instructions in RTL: Assembler. (line 6) 24858* ASSEMBLER_DIALECT: Instruction Output. (line 146) 24859* assigning attribute values to insns: Tagging Insns. (line 6) 24860* assignment operator: Function Basics. (line 6) 24861* asterisk in template: Output Statement. (line 29) 24862* atan2M3 instruction pattern: Standard Names. (line 283) 24863* attr <1>: Tagging Insns. (line 54) 24864* attr: Expressions. (line 154) 24865* attr_flag: Expressions. (line 119) 24866* attribute expressions: Expressions. (line 6) 24867* attribute specifications: Attr Example. (line 6) 24868* attribute specifications example: Attr Example. (line 6) 24869* attributes: Attributes. (line 6) 24870* attributes, defining: Defining Attributes. 24871 (line 6) 24872* attributes, target-specific: Target Attributes. (line 6) 24873* autoincrement addressing, availability: Portability. (line 21) 24874* autoincrement/decrement addressing: Simple Constraints. (line 28) 24875* autoincrement/decrement analysis: Passes. (line 257) 24876* automata_option: Automaton pipeline description. 24877 (line 253) 24878* automaton based pipeline description <1>: Comparison of the two descriptions. 24879 (line 6) 24880* automaton based pipeline description <2>: Automaton pipeline description. 24881 (line 6) 24882* automaton based pipeline description: Processor pipeline description. 24883 (line 6) 24884* automaton based scheduler: Processor pipeline description. 24885 (line 6) 24886* AVOID_CCMODE_COPIES: Values in Registers. 24887 (line 107) 24888* backslash: Output Template. (line 47) 24889* barrier: Insns. (line 166) 24890* barrier and /f: Flags. (line 120) 24891* barrier and /i: Flags. (line 147) 24892* barrier and /v: Flags. (line 33) 24893* BASE_REG_CLASS: Register Classes. (line 107) 24894* basic block reordering: Passes. (line 372) 24895* basic blocks: Passes. (line 251) 24896* bCOND instruction pattern: Standard Names. (line 583) 24897* bcopy, implicit usage: Library Calls. (line 66) 24898* BIGGEST_ALIGNMENT: Storage Layout. (line 168) 24899* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 179) 24900* BImode: Machine Modes. (line 22) 24901* BIND_EXPR: Expression trees. (line 6) 24902* BINFO_TYPE: Classes. (line 6) 24903* bit-fields: Bit-Fields. (line 6) 24904* BIT_AND_EXPR: Expression trees. (line 6) 24905* BIT_IOR_EXPR: Expression trees. (line 6) 24906* BIT_NOT_EXPR: Expression trees. (line 6) 24907* BIT_XOR_EXPR: Expression trees. (line 6) 24908* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 324) 24909* BITS_BIG_ENDIAN: Storage Layout. (line 12) 24910* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 11) 24911* BITS_PER_UNIT: Storage Layout. (line 52) 24912* BITS_PER_WORD: Storage Layout. (line 57) 24913* bitwise complement: Arithmetic. (line 128) 24914* bitwise exclusive-or: Arithmetic. (line 142) 24915* bitwise inclusive-or: Arithmetic. (line 137) 24916* bitwise logical-and: Arithmetic. (line 132) 24917* BLKmode: Machine Modes. (line 97) 24918* BLKmode, and function return values: Calls. (line 23) 24919* BLOCK_REG_PADDING: Register Arguments. (line 211) 24920* bool <1>: Exception Region Output. 24921 (line 79) 24922* bool: Sections. (line 202) 24923* BOOL_TYPE_SIZE: Type Layout. (line 51) 24924* BOOLEAN_TYPE: Types. (line 6) 24925* branch shortening: Passes. (line 393) 24926* BRANCH_COST: Costs. (line 52) 24927* break_out_memory_refs: Addressing Modes. (line 148) 24928* BREAK_STMT: Function Bodies. (line 6) 24929* BSS_SECTION_ASM_OP: Sections. (line 59) 24930* builtin_longjmp instruction pattern: Standard Names. (line 954) 24931* BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 100) 24932* builtin_setjmp_receiver instruction pattern: Standard Names. 24933 (line 944) 24934* builtin_setjmp_setup instruction pattern: Standard Names. (line 933) 24935* byte_mode: Machine Modes. (line 223) 24936* BYTES_BIG_ENDIAN: Storage Layout. (line 24) 24937* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 136) 24938* bzero, implicit usage: Library Calls. (line 66) 24939* C statements for assembler output: Output Statement. (line 6) 24940* C/C++ Internal Representation: Trees. (line 6) 24941* C4X_FLOAT_FORMAT: Storage Layout. (line 399) 24942* C99 math functions, implicit usage: Library Calls. (line 71) 24943* c_register_pragma: Misc. (line 353) 24944* call <1>: Side Effects. (line 82) 24945* call: Flags. (line 241) 24946* call instruction pattern: Standard Names. (line 610) 24947* call usage: Calls. (line 10) 24948* call, in mem: Flags. (line 93) 24949* call-clobbered register: Register Basics. (line 35) 24950* call-saved register: Register Basics. (line 35) 24951* call-used register: Register Basics. (line 35) 24952* CALL_EXPR: Expression trees. (line 6) 24953* call_insn: Insns. (line 94) 24954* call_insn and /f: Flags. (line 120) 24955* call_insn and /i: Flags. (line 147) 24956* call_insn and /j: Flags. (line 186) 24957* call_insn and /s: Flags. (line 38) 24958* call_insn and /u: Flags. (line 19) 24959* call_insn and /v: Flags. (line 33) 24960* CALL_INSN_FUNCTION_USAGE: Insns. (line 100) 24961* call_pop instruction pattern: Standard Names. (line 638) 24962* CALL_POPS_ARGS: Stack Arguments. (line 155) 24963* CALL_REALLY_USED_REGISTERS: Register Basics. (line 46) 24964* CALL_USED_REGISTERS: Register Basics. (line 35) 24965* call_used_regs: Register Basics. (line 59) 24966* call_value instruction pattern: Standard Names. (line 630) 24967* call_value_pop instruction pattern: Standard Names. (line 638) 24968* CALLER_SAVE_PROFITABLE: Caller Saves. (line 11) 24969* calling conventions: Stack and Calling. (line 6) 24970* calling functions in RTL: Calls. (line 6) 24971* CAN_DEBUG_WITHOUT_FP: Run-time Target. (line 222) 24972* CAN_ELIMINATE: Elimination. (line 71) 24973* canadian: Configure Terms. (line 6) 24974* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 382) 24975* canonicalization of instructions: Insn Canonicalizations. 24976 (line 6) 24977* CANONICALIZE_COMPARISON: Condition Code. (line 84) 24978* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 24979 (line 799) 24980* CASE_DROPS_THROUGH: Misc. (line 67) 24981* CASE_USE_BIT_TESTS: Misc. (line 79) 24982* CASE_VALUES_THRESHOLD: Misc. (line 72) 24983* CASE_VECTOR_MODE: Misc. (line 47) 24984* CASE_VECTOR_PC_RELATIVE: Misc. (line 60) 24985* CASE_VECTOR_SHORTEN_MODE: Misc. (line 51) 24986* casesi instruction pattern: Standard Names. (line 718) 24987* cc0: Regs and Memory. (line 182) 24988* cc0, RTL sharing: Sharing. (line 27) 24989* cc0_rtx: Regs and Memory. (line 208) 24990* CC1_SPEC: Driver. (line 118) 24991* CC1PLUS_SPEC: Driver. (line 126) 24992* cc_status: Condition Code. (line 8) 24993* CC_STATUS_MDEP: Condition Code. (line 19) 24994* CC_STATUS_MDEP_INIT: Condition Code. (line 25) 24995* CCmode: Machine Modes. (line 90) 24996* CDImode: Machine Modes. (line 116) 24997* ceilM2 instruction pattern: Standard Names. (line 317) 24998* chain_next: GTY Options. (line 165) 24999* chain_prev: GTY Options. (line 165) 25000* change_address: Standard Names. (line 47) 25001* char <1>: PCH Target. (line 16) 25002* char: Sections. (line 194) 25003* CHAR_TYPE_SIZE: Type Layout. (line 46) 25004* check_stack instruction pattern: Standard Names. (line 886) 25005* CHImode: Machine Modes. (line 116) 25006* class: Classes. (line 6) 25007* class definitions, register: Register Classes. (line 6) 25008* class preference constraints: Class Preferences. (line 6) 25009* CLASS_LIKELY_SPILLED_P: Register Classes. (line 353) 25010* CLASS_MAX_NREGS: Register Classes. (line 370) 25011* CLASS_TYPE_P: Types. (line 81) 25012* classes of RTX codes: RTL Classes. (line 6) 25013* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 25014* CLASSTYPE_HAS_MUTABLE: Classes. (line 78) 25015* CLASSTYPE_NON_POD_P: Classes. (line 83) 25016* CLEANUP_DECL: Function Bodies. (line 6) 25017* CLEANUP_EXPR: Function Bodies. (line 6) 25018* CLEANUP_POINT_EXPR: Expression trees. (line 6) 25019* CLEANUP_STMT: Function Bodies. (line 6) 25020* CLEAR_BY_PIECES_P: Costs. (line 124) 25021* CLEAR_INSN_CACHE: Trampolines. (line 101) 25022* CLEAR_RATIO: Costs. (line 115) 25023* clobber: Side Effects. (line 96) 25024* clrstrM instruction pattern: Standard Names. (line 418) 25025* clz: Arithmetic. (line 178) 25026* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 271) 25027* clzM2 instruction pattern: Standard Names. (line 343) 25028* cmpM instruction pattern: Standard Names. (line 372) 25029* cmpmemM instruction pattern: Standard Names. (line 443) 25030* cmpstrM instruction pattern: Standard Names. (line 431) 25031* code generation RTL sequences: Expander Definitions. 25032 (line 6) 25033* code motion: Passes. (line 204) 25034* code_label: Insns. (line 125) 25035* code_label and /i: Flags. (line 53) 25036* code_label and /v: Flags. (line 33) 25037* CODE_LABEL_NUMBER: Insns. (line 125) 25038* codes, RTL expression: RTL Objects. (line 47) 25039* COImode: Machine Modes. (line 116) 25040* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 25041* COLLECT_EXPORT_LIST: Misc. (line 635) 25042* COLLECT_PARSE_FLAG: Macros for Initialization. 25043 (line 106) 25044* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 25045 (line 44) 25046* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 25047 (line 33) 25048* combiner pass: Regs and Memory. (line 148) 25049* common subexpression elimination: Passes. (line 171) 25050* compare: Arithmetic. (line 42) 25051* compare, canonicalization of: Insn Canonicalizations. 25052 (line 31) 25053* compiler passes and files: Passes. (line 6) 25054* complement, bitwise: Arithmetic. (line 128) 25055* COMPLEX_CST: Expression trees. (line 6) 25056* COMPLEX_EXPR: Expression trees. (line 6) 25057* COMPLEX_TYPE: Types. (line 6) 25058* COMPONENT_REF: Expression trees. (line 6) 25059* COMPOUND_BODY: Function Bodies. (line 6) 25060* COMPOUND_EXPR: Expression trees. (line 6) 25061* COMPOUND_LITERAL_EXPR: Expression trees. (line 6) 25062* COMPOUND_LITERAL_EXPR_DECL: Expression trees. (line 470) 25063* COMPOUND_LITERAL_EXPR_DECL_STMT: Expression trees. (line 470) 25064* COMPOUND_STMT: Function Bodies. (line 6) 25065* computing the length of an insn: Insn Lengths. (line 6) 25066* concat and /u: Flags. (line 153) 25067* cond: Comparisons. (line 87) 25068* cond and attributes: Expressions. (line 37) 25069* cond_exec: Side Effects. (line 241) 25070* COND_EXPR: Expression trees. (line 6) 25071* condition code register: Regs and Memory. (line 182) 25072* condition code status: Condition Code. (line 6) 25073* condition codes: Comparisons. (line 17) 25074* conditional execution: Conditional Execution. 25075 (line 6) 25076* CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60) 25077* conditional_trap instruction pattern: Standard Names. (line 1020) 25078* conditions, in patterns: Patterns. (line 44) 25079* configuration file <1>: Host Misc. (line 6) 25080* configuration file: Filesystem. (line 6) 25081* configure terms: Configure Terms. (line 6) 25082* CONJ_EXPR: Expression trees. (line 6) 25083* const and /i: Flags. (line 147) 25084* CONST0_RTX: Constants. (line 70) 25085* const0_rtx: Constants. (line 13) 25086* CONST1_RTX: Constants. (line 70) 25087* const1_rtx: Constants. (line 13) 25088* CONST2_RTX: Constants. (line 70) 25089* const2_rtx: Constants. (line 13) 25090* CONST_DECL: Declarations. (line 6) 25091* const_double: Constants. (line 29) 25092* const_double, RTL sharing: Sharing. (line 29) 25093* CONST_DOUBLE_CHAIN: Constants. (line 48) 25094* CONST_DOUBLE_LOW: Constants. (line 57) 25095* CONST_DOUBLE_MEM: Constants. (line 48) 25096* CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Register Classes. (line 429) 25097* CONST_DOUBLE_OK_FOR_LETTER_P: Register Classes. (line 414) 25098* const_int: Constants. (line 8) 25099* const_int and attribute tests: Expressions. (line 47) 25100* const_int and attributes: Expressions. (line 10) 25101* const_int, RTL sharing: Sharing. (line 23) 25102* CONST_OK_FOR_CONSTRAINT_P: Register Classes. (line 409) 25103* CONST_OK_FOR_LETTER_P: Register Classes. (line 400) 25104* CONST_OR_PURE_CALL_P: Flags. (line 19) 25105* const_string: Constants. (line 79) 25106* const_string and attributes: Expressions. (line 20) 25107* const_true_rtx: Constants. (line 23) 25108* const_vector: Constants. (line 36) 25109* const_vector, RTL sharing: Sharing. (line 32) 25110* constant attributes: Constant Attributes. 25111 (line 6) 25112* constant definitions: Constant Definitions. 25113 (line 6) 25114* constant folding: Passes. (line 79) 25115* constant propagation: Passes. (line 171) 25116* CONSTANT_ADDRESS_P: Addressing Modes. (line 29) 25117* CONSTANT_ALIGNMENT: Storage Layout. (line 213) 25118* CONSTANT_P: Addressing Modes. (line 35) 25119* CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 25120* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 64) 25121* constants in constraints: Simple Constraints. (line 58) 25122* constm1_rtx: Constants. (line 13) 25123* constraint modifier characters: Modifiers. (line 6) 25124* constraint, matching: Simple Constraints. (line 130) 25125* CONSTRAINT_LEN: Register Classes. (line 124) 25126* constraints: Constraints. (line 6) 25127* constraints, machine specific: Machine Constraints. 25128 (line 6) 25129* CONSTRUCTOR: Expression trees. (line 6) 25130* constructor: Function Basics. (line 6) 25131* constructors, automatic calls: Collect2. (line 15) 25132* constructors, output of: Initialization. (line 6) 25133* container: Containers. (line 6) 25134* CONTINUE_STMT: Function Bodies. (line 6) 25135* contributors: Contributors. (line 6) 25136* controlling register usage: Register Basics. (line 76) 25137* controlling the compilation driver: Driver. (line 6) 25138* conventions, run-time: Interface. (line 6) 25139* conversions: Conversions. (line 6) 25140* CONVERT_EXPR: Expression trees. (line 6) 25141* copy constructor: Function Basics. (line 6) 25142* copy propagation: Passes. (line 181) 25143* copy_rtx: Addressing Modes. (line 200) 25144* copy_rtx_if_shared: Sharing. (line 64) 25145* cosM2 instruction pattern: Standard Names. (line 242) 25146* costs of instructions: Costs. (line 6) 25147* CP_INTEGRAL_TYPE: Types. (line 73) 25148* cp_namespace_decls: Namespaces. (line 44) 25149* CP_TYPE_CONST_NON_VOLATILE_P: Types. (line 46) 25150* CP_TYPE_CONST_P: Types. (line 37) 25151* CP_TYPE_QUALS: Types. (line 6) 25152* CP_TYPE_RESTRICT_P: Types. (line 43) 25153* CP_TYPE_VOLATILE_P: Types. (line 40) 25154* CPLUSPLUS_CPP_SPEC: Driver. (line 113) 25155* CPP_SPEC: Driver. (line 106) 25156* CQImode: Machine Modes. (line 116) 25157* cross compilation and floating point: Floating Point. (line 6) 25158* CRT_CALL_STATIC_FUNCTION: Sections. (line 80) 25159* CRTSTUFF_T_CFLAGS: Target Fragment. (line 35) 25160* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39) 25161* CSImode: Machine Modes. (line 116) 25162* CTImode: Machine Modes. (line 116) 25163* ctz: Arithmetic. (line 186) 25164* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 272) 25165* ctzM2 instruction pattern: Standard Names. (line 350) 25166* CUMULATIVE_ARGS: Register Arguments. (line 124) 25167* current_function_epilogue_delay_list: Function Entry. (line 186) 25168* current_function_is_leaf: Leaf Functions. (line 51) 25169* current_function_outgoing_args_size: Stack Arguments. (line 45) 25170* current_function_pops_args: Function Entry. (line 106) 25171* current_function_pretend_args_size: Function Entry. (line 112) 25172* current_function_uses_only_leaf_regs: Leaf Functions. (line 51) 25173* current_insn_predicate: Conditional Execution. 25174 (line 26) 25175* data bypass <1>: Comparison of the two descriptions. 25176 (line 6) 25177* data bypass: Automaton pipeline description. 25178 (line 63) 25179* data dependence delays: Processor pipeline description. 25180 (line 6) 25181* data flow analysis: Passes. (line 251) 25182* data structures: Per-Function Data. (line 6) 25183* DATA_ALIGNMENT: Storage Layout. (line 200) 25184* data_section: Sections. (line 101) 25185* DATA_SECTION_ASM_OP: Sections. (line 33) 25186* DBR_OUTPUT_SEQEND: Instruction Output. (line 107) 25187* dbr_sequence_length: Instruction Output. (line 106) 25188* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 107) 25189* DBX_CONTIN_CHAR: DBX Options. (line 66) 25190* DBX_CONTIN_LENGTH: DBX Options. (line 56) 25191* DBX_DEBUGGING_INFO: DBX Options. (line 9) 25192* DBX_FUNCTION_FIRST: DBX Options. (line 101) 25193* DBX_MEMPARM_STABS_LETTER: DBX Options. (line 97) 25194* DBX_NO_XREFS: DBX Options. (line 50) 25195* DBX_OUTPUT_FUNCTION_END: DBX Hooks. (line 22) 25196* DBX_OUTPUT_LBRAC: DBX Hooks. (line 9) 25197* DBX_OUTPUT_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 18) 25198* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 26) 25199* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9) 25200* DBX_OUTPUT_NFUN: DBX Hooks. (line 18) 25201* DBX_OUTPUT_RBRAC: DBX Hooks. (line 15) 25202* DBX_OUTPUT_STANDARD_TYPES: DBX Hooks. (line 29) 25203* DBX_REGISTER_NUMBER: All Debuggers. (line 9) 25204* DBX_REGPARM_STABS_CODE: DBX Options. (line 87) 25205* DBX_REGPARM_STABS_LETTER: DBX Options. (line 92) 25206* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82) 25207* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73) 25208* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78) 25209* DBX_USE_BINCL: DBX Options. (line 112) 25210* DCmode: Machine Modes. (line 111) 25211* De Morgan's law: Insn Canonicalizations. 25212 (line 48) 25213* dead code: Passes. (line 139) 25214* dead_or_set_p: define_peephole. (line 65) 25215* DEBUG_SYMS_TEXT: DBX Options. (line 25) 25216* DEBUGGER_ARG_OFFSET: All Debuggers. (line 37) 25217* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28) 25218* debugging information generation: Passes. (line 421) 25219* DECL_ALIGN: Declarations. (line 6) 25220* DECL_ANTICIPATED: Function Basics. (line 41) 25221* DECL_ARGUMENTS: Function Basics. (line 156) 25222* DECL_ARRAY_DELETE_OPERATOR_P: Function Basics. (line 177) 25223* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 25224* DECL_ARTIFICIAL: Declarations. (line 29) 25225* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 25226* DECL_ATTRIBUTES: Attributes. (line 22) 25227* DECL_BASE_CONSTRUCTOR_P: Function Basics. (line 87) 25228* DECL_CLASS_SCOPE_P: Declarations. (line 46) 25229* DECL_COMPLETE_CONSTRUCTOR_P: Function Basics. (line 83) 25230* DECL_COMPLETE_DESTRUCTOR_P: Function Basics. (line 97) 25231* DECL_CONST_MEMFUNC_P: Function Basics. (line 70) 25232* DECL_CONSTRUCTOR_P: Function Basics. (line 6) 25233* DECL_CONTEXT: Namespaces. (line 26) 25234* DECL_CONV_FN_P: Function Basics. (line 6) 25235* DECL_COPY_CONSTRUCTOR_P: Function Basics. (line 91) 25236* DECL_DESTRUCTOR_P: Function Basics. (line 6) 25237* DECL_EXTERN_C_FUNCTION_P: Function Basics. (line 45) 25238* DECL_EXTERNAL <1>: Function Basics. (line 31) 25239* DECL_EXTERNAL: Declarations. (line 6) 25240* DECL_FUNCTION_MEMBER_P: Function Basics. (line 6) 25241* DECL_FUNCTION_SCOPE_P: Declarations. (line 49) 25242* DECL_GLOBAL_CTOR_P: Function Basics. (line 6) 25243* DECL_GLOBAL_DTOR_P: Function Basics. (line 6) 25244* DECL_INITIAL: Declarations. (line 6) 25245* DECL_LINKONCE_P: Function Basics. (line 6) 25246* DECL_LOCAL_FUNCTION_P: Function Basics. (line 37) 25247* DECL_MAIN_P: Function Basics. (line 7) 25248* DECL_NAME <1>: Function Basics. (line 6) 25249* DECL_NAME <2>: Declarations. (line 12) 25250* DECL_NAME: Namespaces. (line 15) 25251* DECL_NAMESPACE_ALIAS: Namespaces. (line 30) 25252* DECL_NAMESPACE_SCOPE_P: Declarations. (line 42) 25253* DECL_NAMESPACE_STD_P: Namespaces. (line 40) 25254* DECL_NON_THUNK_FUNCTION_P: Function Basics. (line 137) 25255* DECL_NONCONVERTING_P: Function Basics. (line 79) 25256* DECL_NONSTATIC_MEMBER_FUNCTION_P: Function Basics. (line 67) 25257* DECL_OVERLOADED_OPERATOR_P: Function Basics. (line 6) 25258* DECL_RESULT: Function Basics. (line 161) 25259* DECL_SIZE: Declarations. (line 6) 25260* DECL_SOURCE_FILE: Declarations. (line 19) 25261* DECL_SOURCE_LINE: Declarations. (line 25) 25262* DECL_STATIC_FUNCTION_P: Function Basics. (line 64) 25263* DECL_STMT: Function Bodies. (line 6) 25264* DECL_STMT_DECL: Function Bodies. (line 6) 25265* DECL_THUNK_P: Function Basics. (line 115) 25266* DECL_VOLATILE_MEMFUNC_P: Function Basics. (line 73) 25267* declaration: Declarations. (line 6) 25268* declarations, RTL: RTL Declarations. (line 6) 25269* DECLARE_LIBRARY_RENAMES: Library Calls. (line 9) 25270* decrement_and_branch_until_zero instruction pattern: Standard Names. 25271 (line 761) 25272* default: GTY Options. (line 75) 25273* default_file_start: File Framework. (line 9) 25274* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18) 25275* DEFAULT_MAIN_RETURN: Misc. (line 441) 25276* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 25277* DEFAULT_SHORT_ENUMS: Type Layout. (line 96) 25278* DEFAULT_SIGNED_CHAR: Type Layout. (line 90) 25279* define_asm_attributes: Tagging Insns. (line 73) 25280* define_attr: Defining Attributes. 25281 (line 6) 25282* define_automaton: Automaton pipeline description. 25283 (line 10) 25284* define_bypass: Automaton pipeline description. 25285 (line 154) 25286* define_cond_exec: Conditional Execution. 25287 (line 13) 25288* define_constants: Constant Definitions. 25289 (line 6) 25290* define_cpu_unit: Automaton pipeline description. 25291 (line 25) 25292* define_delay: Delay Slots. (line 25) 25293* define_expand: Expander Definitions. 25294 (line 11) 25295* define_function_unit: Old pipeline description. 25296 (line 33) 25297* define_insn: Patterns. (line 6) 25298* define_insn example: Example. (line 6) 25299* define_insn_and_split: Insn Splitting. (line 170) 25300* define_insn_reservation: Automaton pipeline description. 25301 (line 63) 25302* define_peephole: define_peephole. (line 6) 25303* define_peephole2: define_peephole2. (line 6) 25304* define_query_cpu_unit: Automaton pipeline description. 25305 (line 47) 25306* define_reservation: Automaton pipeline description. 25307 (line 143) 25308* define_split: Insn Splitting. (line 32) 25309* defining attributes and their values: Defining Attributes. 25310 (line 6) 25311* defining jump instruction patterns: Jump Patterns. (line 6) 25312* defining looping instruction patterns: Looping Patterns. (line 6) 25313* defining peephole optimizers: Peephole Definitions. 25314 (line 6) 25315* defining RTL sequences for code generation: Expander Definitions. 25316 (line 6) 25317* delay slots, defining: Delay Slots. (line 6) 25318* DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 168) 25319* delayed branch scheduling: Passes. (line 384) 25320* deletable: GTY Options. (line 137) 25321* Dependent Patterns: Dependent Patterns. (line 6) 25322* desc: GTY Options. (line 75) 25323* destructor: Function Basics. (line 6) 25324* destructors, output of: Initialization. (line 6) 25325* deterministic finite state automaton <1>: Automaton pipeline description. 25326 (line 253) 25327* deterministic finite state automaton: Processor pipeline description. 25328 (line 6) 25329* DFA_PIPELINE_INTERFACE: Scheduling. (line 275) 25330* DFmode: Machine Modes. (line 73) 25331* digits in constraint: Simple Constraints. (line 118) 25332* DImode: Machine Modes. (line 45) 25333* DIR_SEPARATOR: Filesystem. (line 18) 25334* DIR_SEPARATOR_2: Filesystem. (line 19) 25335* directory options .md: Including Patterns. (line 44) 25336* disabling certain registers: Register Basics. (line 76) 25337* dispatch table: Dispatch Tables. (line 8) 25338* div: Arithmetic. (line 99) 25339* div and attributes: Expressions. (line 64) 25340* division: Arithmetic. (line 99) 25341* divM3 instruction pattern: Standard Names. (line 167) 25342* divmodM4 instruction pattern: Standard Names. (line 197) 25343* DO_BODY: Function Bodies. (line 6) 25344* DO_COND: Function Bodies. (line 6) 25345* DO_STMT: Function Bodies. (line 6) 25346* DOLLARS_IN_IDENTIFIERS: Misc. (line 423) 25347* doloop_begin instruction pattern: Standard Names. (line 792) 25348* doloop_end instruction pattern: Standard Names. (line 771) 25349* DONE: Expander Definitions. 25350 (line 74) 25351* DOUBLE_TYPE_SIZE: Type Layout. (line 60) 25352* driver: Driver. (line 6) 25353* DRIVER_SELF_SPECS: Driver. (line 71) 25354* DUMPFILE_FORMAT: Filesystem. (line 67) 25355* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 36) 25356* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13) 25357* DWARF2_FRAME_INFO: SDB and DWARF. (line 23) 25358* DWARF2_FRAME_REG_OUT: Frame Registers. (line 133) 25359* DWARF2_GENERATE_TEXT_SECTION_LABEL: SDB and DWARF. (line 29) 25360* DWARF2_UNWIND_INFO: Exception Region Output. 25361 (line 34) 25362* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 136) 25363* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 25364 (line 55) 25365* DWARF_FRAME_REGISTERS: Frame Registers. (line 93) 25366* DWARF_FRAME_REGNUM: Frame Registers. (line 125) 25367* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 117) 25368* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 83) 25369* E in constraint: Simple Constraints. (line 77) 25370* earlyclobber operand: Modifiers. (line 25) 25371* EDOM, implicit usage: Library Calls. (line 48) 25372* EH_FRAME_IN_DATA_SECTION: Exception Region Output. 25373 (line 20) 25374* EH_FRAME_SECTION_NAME: Exception Region Output. 25375 (line 10) 25376* eh_return instruction pattern: Standard Names. (line 960) 25377* EH_RETURN_DATA_REGNO: Exception Handling. (line 7) 25378* EH_RETURN_HANDLER_RTX: Exception Handling. (line 39) 25379* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22) 25380* EH_USES: Function Entry. (line 163) 25381* ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 174) 25382* ELIMINABLE_REGS: Elimination. (line 44) 25383* ELSE_CLAUSE: Function Bodies. (line 6) 25384* EMIT_MODE_SET: Mode Switching. (line 74) 25385* EMPTY_CLASS_EXPR: Function Bodies. (line 6) 25386* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 237) 25387* ENABLE_EXECUTE_STACK: Trampolines. (line 111) 25388* ENDFILE_SPEC: Driver. (line 195) 25389* endianness: Portability. (line 21) 25390* enum machine_mode: Machine Modes. (line 6) 25391* enum reg_class: Register Classes. (line 65) 25392* ENUMERAL_TYPE: Types. (line 6) 25393* epilogue: Function Entry. (line 6) 25394* epilogue instruction pattern: Standard Names. (line 992) 25395* EPILOGUE_USES: Function Entry. (line 157) 25396* eq: Comparisons. (line 49) 25397* eq and attributes: Expressions. (line 64) 25398* eq_attr: Expressions. (line 85) 25399* EQ_EXPR: Expression trees. (line 6) 25400* equal: Comparisons. (line 49) 25401* errno, implicit usage: Library Calls. (line 60) 25402* escape sequences: Escape Sequences. (line 6) 25403* exception handling: Exception Handling. (line 6) 25404* exception_receiver instruction pattern: Standard Names. (line 924) 25405* exclamation point: Multi-Alternative. (line 47) 25406* exclusion_set: Automaton pipeline description. 25407 (line 172) 25408* exclusive-or, bitwise: Arithmetic. (line 142) 25409* EXIT_EXPR: Expression trees. (line 6) 25410* EXIT_IGNORE_STACK: Function Entry. (line 145) 25411* expander definitions: Expander Definitions. 25412 (line 6) 25413* expM2 instruction pattern: Standard Names. (line 258) 25414* expr_list: Insns. (line 530) 25415* EXPR_STMT: Function Bodies. (line 6) 25416* EXPR_STMT_EXPR: Function Bodies. (line 6) 25417* expression: Expression trees. (line 6) 25418* expression codes: RTL Objects. (line 47) 25419* extendMN2 instruction pattern: Standard Names. (line 497) 25420* extensible constraints: Simple Constraints. (line 161) 25421* EXTRA_ADDRESS_CONSTRAINT: Register Classes. (line 483) 25422* EXTRA_CONSTRAINT: Register Classes. (line 434) 25423* EXTRA_CONSTRAINT_STR: Register Classes. (line 455) 25424* EXTRA_MEMORY_CONSTRAINT: Register Classes. (line 460) 25425* EXTRA_SECTION_FUNCTIONS: Sections. (line 102) 25426* EXTRA_SECTIONS: Sections. (line 97) 25427* EXTRA_SPECS: Driver. (line 222) 25428* extv instruction pattern: Standard Names. (line 506) 25429* extzv instruction pattern: Standard Names. (line 520) 25430* F in constraint: Simple Constraints. (line 82) 25431* FAIL: Expander Definitions. 25432 (line 80) 25433* FATAL_EXIT_CODE: Host Misc. (line 6) 25434* FDL, GNU Free Documentation License: GNU Free Documentation License. 25435 (line 6) 25436* features, optional, in system conventions: Run-time Target. 25437 (line 54) 25438* ffs: Arithmetic. (line 172) 25439* ffsM2 instruction pattern: Standard Names. (line 333) 25440* FIELD_DECL: Declarations. (line 6) 25441* file_end_indicate_exec_stack: File Framework. (line 41) 25442* FILE_STMT: Function Bodies. (line 6) 25443* FILE_STMT_FILENAME: Function Bodies. (line 6) 25444* files and passes of the compiler: Passes. (line 6) 25445* files, generated: Files. (line 6) 25446* final pass: Passes. (line 409) 25447* final_absence_set: Automaton pipeline description. 25448 (line 172) 25449* FINAL_PRESCAN_INSN: Instruction Output. (line 46) 25450* final_presence_set: Automaton pipeline description. 25451 (line 172) 25452* FINAL_REG_PARM_STACK_SPACE: Stack Arguments. (line 71) 25453* final_scan_insn: Function Entry. (line 186) 25454* final_sequence: Instruction Output. (line 117) 25455* FINALIZE_PIC: PIC. (line 31) 25456* FIND_BASE_TERM: Addressing Modes. (line 130) 25457* FINI_SECTION_ASM_OP: Sections. (line 74) 25458* finite state automaton minimization: Automaton pipeline description. 25459 (line 253) 25460* FIRST_PARM_OFFSET: Frame Layout. (line 67) 25461* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 25462* FIRST_PSEUDO_REGISTER: Register Basics. (line 9) 25463* FIRST_STACK_REG: Stack Registers. (line 23) 25464* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 25465* fix: Conversions. (line 67) 25466* FIX_TRUNC_EXPR: Expression trees. (line 6) 25467* fix_truncMN2 instruction pattern: Standard Names. (line 484) 25468* fixed register: Register Basics. (line 15) 25469* FIXED_REGISTERS: Register Basics. (line 15) 25470* fixed_regs: Register Basics. (line 59) 25471* fixMN2 instruction pattern: Standard Names. (line 467) 25472* FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 123) 25473* fixuns_truncMN2 instruction pattern: Standard Names. (line 488) 25474* fixunsMN2 instruction pattern: Standard Names. (line 473) 25475* flags in RTL expression: Flags. (line 6) 25476* float: Conversions. (line 59) 25477* FLOAT_EXPR: Expression trees. (line 6) 25478* float_extend: Conversions. (line 34) 25479* FLOAT_STORE_FLAG_VALUE: Misc. (line 264) 25480* float_truncate: Conversions. (line 54) 25481* FLOAT_TYPE_SIZE: Type Layout. (line 56) 25482* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 43) 25483* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 25484 (line 140) 25485* floating point and cross compilation: Floating Point. (line 6) 25486* Floating Point Emulation: Target Fragment. (line 15) 25487* floating point emulation library, US Software GOFAST: Library Calls. 25488 (line 34) 25489* floatMN2 instruction pattern: Standard Names. (line 459) 25490* floatunsMN2 instruction pattern: Standard Names. (line 463) 25491* floorM2 instruction pattern: Standard Names. (line 293) 25492* FOR_BODY: Function Bodies. (line 6) 25493* FOR_COND: Function Bodies. (line 6) 25494* FOR_EXPR: Function Bodies. (line 6) 25495* FOR_INIT_STMT: Function Bodies. (line 6) 25496* FOR_STMT: Function Bodies. (line 6) 25497* FORCE_CODE_SECTION_ALIGN: Sections. (line 91) 25498* FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN: Storage Layout. (line 155) 25499* force_reg: Standard Names. (line 36) 25500* frame layout: Frame Layout. (line 6) 25501* FRAME_GROWS_DOWNWARD: Frame Layout. (line 31) 25502* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 25503 (line 69) 25504* frame_pointer_needed: Function Entry. (line 34) 25505* FRAME_POINTER_REGNUM: Frame Registers. (line 14) 25506* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 25507 (line 74) 25508* FRAME_POINTER_REQUIRED: Elimination. (line 9) 25509* frame_pointer_rtx: Frame Registers. (line 85) 25510* frame_related: Flags. (line 246) 25511* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 25512 (line 120) 25513* frame_related, in mem: Flags. (line 79) 25514* frame_related, in reg: Flags. (line 107) 25515* frame_related, in symbol_ref: Flags. (line 190) 25516* ftruncM2 instruction pattern: Standard Names. (line 479) 25517* function: Functions. (line 6) 25518* function body: Function Bodies. (line 6) 25519* function call conventions: Interface. (line 6) 25520* function entry and exit: Function Entry. (line 6) 25521* function units, for scheduling: Old pipeline description. 25522 (line 6) 25523* function-call insns: Calls. (line 6) 25524* FUNCTION_ARG: Register Arguments. (line 11) 25525* FUNCTION_ARG_ADVANCE: Register Arguments. (line 175) 25526* FUNCTION_ARG_BOUNDARY: Register Arguments. (line 221) 25527* FUNCTION_ARG_CALLEE_COPIES: Register Arguments. (line 113) 25528* FUNCTION_ARG_PADDING: Register Arguments. (line 186) 25529* FUNCTION_ARG_PARTIAL_NREGS: Register Arguments. (line 81) 25530* FUNCTION_ARG_PASS_BY_REFERENCE: Register Arguments. (line 100) 25531* FUNCTION_ARG_REGNO_P: Register Arguments. (line 226) 25532* FUNCTION_BOUNDARY: Storage Layout. (line 165) 25533* FUNCTION_DECL: Functions. (line 6) 25534* FUNCTION_INCOMING_ARG: Register Arguments. (line 67) 25535* FUNCTION_MODE: Misc. (line 301) 25536* FUNCTION_OUTGOING_VALUE: Scalar Return. (line 36) 25537* FUNCTION_PROFILER: Profiling. (line 9) 25538* FUNCTION_TYPE: Types. (line 6) 25539* FUNCTION_VALUE: Scalar Return. (line 10) 25540* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 70) 25541* functions, leaf: Leaf Functions. (line 6) 25542* fundamental type: Types. (line 6) 25543* g in constraint: Simple Constraints. (line 108) 25544* G in constraint: Simple Constraints. (line 86) 25545* GCC and portability: Portability. (line 6) 25546* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 25547* GCOV_TYPE_SIZE: Type Layout. (line 148) 25548* ge: Comparisons. (line 69) 25549* ge and attributes: Expressions. (line 64) 25550* GE_EXPR: Expression trees. (line 6) 25551* GEN_ERRNO_RTX: Library Calls. (line 61) 25552* gencodes: Passes. (line 104) 25553* genconfig: Passes. (line 445) 25554* general_operand: RTL Template. (line 57) 25555* GENERAL_REGS: Register Classes. (line 23) 25556* generated files: Files. (line 6) 25557* generating assembler output: Output Statement. (line 6) 25558* generating insns: RTL Template. (line 6) 25559* genflags: Passes. (line 104) 25560* get_attr: Expressions. (line 80) 25561* get_attr_length: Insn Lengths. (line 46) 25562* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 220) 25563* GET_CODE: RTL Objects. (line 47) 25564* get_frame_size: Elimination. (line 31) 25565* get_insns: Insns. (line 34) 25566* get_last_insn: Insns. (line 34) 25567* GET_MODE: Machine Modes. (line 175) 25568* GET_MODE_ALIGNMENT: Machine Modes. (line 207) 25569* GET_MODE_BITSIZE: Machine Modes. (line 199) 25570* GET_MODE_CLASS: Machine Modes. (line 189) 25571* GET_MODE_MASK: Machine Modes. (line 202) 25572* GET_MODE_NAME: Machine Modes. (line 186) 25573* GET_MODE_NUNITS: Machine Modes. (line 216) 25574* GET_MODE_SIZE: Machine Modes. (line 196) 25575* GET_MODE_UNIT_SIZE: Machine Modes. (line 210) 25576* GET_MODE_WIDER_MODE: Machine Modes. (line 192) 25577* GET_RTX_CLASS: RTL Classes. (line 6) 25578* GET_RTX_FORMAT: RTL Classes. (line 122) 25579* GET_RTX_LENGTH: RTL Classes. (line 119) 25580* geu: Comparisons. (line 69) 25581* geu and attributes: Expressions. (line 64) 25582* GGC: Type Information. (line 6) 25583* global common subexpression elimination: Passes. (line 181) 25584* global register allocation: Passes. (line 332) 25585* GLOBAL_INIT_PRIORITY: Function Basics. (line 6) 25586* global_regs: Register Basics. (line 59) 25587* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 48) 25588* GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 208) 25589* GOFAST, floating point emulation library: Library Calls. (line 34) 25590* gofast_maybe_init_libfuncs: Library Calls. (line 34) 25591* GOTO_DESTINATION: Function Bodies. (line 6) 25592* GOTO_FAKE_P: Function Bodies. (line 6) 25593* GOTO_STMT: Function Bodies. (line 6) 25594* graph coloring register allocation: Passes. (line 336) 25595* greater than: Comparisons. (line 57) 25596* gt: Comparisons. (line 57) 25597* gt and attributes: Expressions. (line 64) 25598* GT_EXPR: Expression trees. (line 6) 25599* gtu: Comparisons. (line 61) 25600* gtu and attributes: Expressions. (line 64) 25601* GTY: Type Information. (line 6) 25602* H in constraint: Simple Constraints. (line 86) 25603* HANDLE_PRAGMA_PACK_PUSH_POP: Misc. (line 412) 25604* HANDLE_SYSV_PRAGMA: Misc. (line 383) 25605* HANDLER: Function Bodies. (line 6) 25606* HANDLER_BODY: Function Bodies. (line 6) 25607* HANDLER_PARMS: Function Bodies. (line 6) 25608* hard registers: Regs and Memory. (line 9) 25609* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20) 25610* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53) 25611* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20) 25612* HARD_REGNO_MODE_OK: Values in Registers. 25613 (line 31) 25614* HARD_REGNO_NREGS: Values in Registers. 25615 (line 11) 25616* HAS_INIT_SECTION: Macros for Initialization. 25617 (line 19) 25618* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 25619* HAVE_POST_DECREMENT: Addressing Modes. (line 12) 25620* HAVE_POST_INCREMENT: Addressing Modes. (line 11) 25621* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18) 25622* HAVE_POST_MODIFY_REG: Addressing Modes. (line 24) 25623* HAVE_PRE_DECREMENT: Addressing Modes. (line 10) 25624* HAVE_PRE_INCREMENT: Addressing Modes. (line 9) 25625* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17) 25626* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23) 25627* HCmode: Machine Modes. (line 111) 25628* HFmode: Machine Modes. (line 58) 25629* high: Constants. (line 114) 25630* HImode: Machine Modes. (line 29) 25631* HImode, in insn: Insns. (line 241) 25632* host configuration: Host Config. (line 6) 25633* host functions: Host Common. (line 6) 25634* host hooks: Host Common. (line 6) 25635* host makefile fragment: Host Fragment. (line 6) 25636* HOST_BIT_BUCKET: Filesystem. (line 51) 25637* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 25638* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12) 25639* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 28) 25640* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 25641* HOT_TEXT_SECTION_NAME: Sections. (line 23) 25642* I in constraint: Simple Constraints. (line 69) 25643* i in constraint: Simple Constraints. (line 58) 25644* IBM_FLOAT_FORMAT: Storage Layout. (line 396) 25645* identifier: Identifiers. (line 6) 25646* IDENTIFIER_LENGTH: Identifiers. (line 20) 25647* IDENTIFIER_NODE: Identifiers. (line 6) 25648* IDENTIFIER_OPNAME_P: Identifiers. (line 25) 25649* IDENTIFIER_POINTER: Identifiers. (line 15) 25650* IDENTIFIER_TYPENAME_P: Identifiers. (line 31) 25651* IEEE_FLOAT_FORMAT: Storage Layout. (line 386) 25652* if conversion: Passes. (line 277) 25653* IF_COND: Function Bodies. (line 6) 25654* if_marked: GTY Options. (line 143) 25655* IF_STMT: Function Bodies. (line 6) 25656* if_then_else: Comparisons. (line 77) 25657* if_then_else and attributes: Expressions. (line 32) 25658* if_then_else usage: Side Effects. (line 52) 25659* IFCVT_EXTRA_FIELDS: Misc. (line 553) 25660* IFCVT_INIT_EXTRA_FIELDS: Misc. (line 548) 25661* IFCVT_MODIFY_CANCEL: Misc. (line 542) 25662* IFCVT_MODIFY_FINAL: Misc. (line 536) 25663* IFCVT_MODIFY_INSN: Misc. (line 530) 25664* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 523) 25665* IFCVT_MODIFY_TESTS: Misc. (line 512) 25666* IMAGPART_EXPR: Expression trees. (line 6) 25667* immediate_operand: RTL Template. (line 72) 25668* IMMEDIATE_PREFIX: Instruction Output. (line 127) 25669* in_data: Sections. (line 96) 25670* in_struct: Flags. (line 261) 25671* in_struct, in code_label and note: Flags. (line 53) 25672* in_struct, in insn: Flags. (line 29) 25673* in_struct, in insn and jump_insn and call_insn: Flags. (line 38) 25674* in_struct, in insn, jump_insn and call_insn: Flags. (line 173) 25675* in_struct, in label_ref: Flags. (line 48) 25676* in_struct, in mem: Flags. (line 64) 25677* in_struct, in reg: Flags. (line 102) 25678* in_struct, in subreg: Flags. (line 212) 25679* in_text: Sections. (line 96) 25680* include: Including Patterns. (line 6) 25681* INCLUDE_DEFAULTS: Driver. (line 402) 25682* inclusive-or, bitwise: Arithmetic. (line 137) 25683* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 143) 25684* INCOMING_REGNO: Register Basics. (line 98) 25685* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 123) 25686* INDEX_REG_CLASS: Register Classes. (line 118) 25687* indirect_jump instruction pattern: Standard Names. (line 714) 25688* INDIRECT_REF: Expression trees. (line 6) 25689* INIT_CUMULATIVE_ARGS: Register Arguments. (line 138) 25690* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 166) 25691* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 159) 25692* INIT_ENVIRONMENT: Driver. (line 341) 25693* INIT_EXPANDERS: Per-Function Data. (line 39) 25694* INIT_EXPR: Expression trees. (line 6) 25695* init_machine_status: Per-Function Data. (line 45) 25696* init_one_libfunc: Library Calls. (line 15) 25697* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 25698 (line 10) 25699* INIT_SECTION_ASM_OP: Sections. (line 68) 25700* INITIAL_ELIMINATION_OFFSET: Elimination. (line 79) 25701* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 32) 25702* initialization routines: Initialization. (line 6) 25703* INITIALIZE_TRAMPOLINE: Trampolines. (line 56) 25704* inline on rtx, automatic: Passes. (line 113) 25705* inline on trees, automatic: Passes. (line 73) 25706* inlining: Target Attributes. (line 69) 25707* insn: Insns. (line 64) 25708* insn and /f: Flags. (line 120) 25709* insn and /i: Flags. (line 147) 25710* insn and /j: Flags. (line 182) 25711* insn and /s: Flags. (line 29) 25712* insn and /u: Flags. (line 24) 25713* insn and /v: Flags. (line 33) 25714* insn attributes: Insn Attributes. (line 6) 25715* insn canonicalization: Insn Canonicalizations. 25716 (line 6) 25717* insn includes: Including Patterns. (line 6) 25718* insn lengths, computing: Insn Lengths. (line 6) 25719* insn splitting: Insn Splitting. (line 6) 25720* insn-attr.h: Defining Attributes. 25721 (line 24) 25722* INSN_ANNULLED_BRANCH_P: Flags. (line 24) 25723* INSN_CODE: Insns. (line 267) 25724* INSN_DEAD_CODE_P: Flags. (line 29) 25725* INSN_DELETED_P: Flags. (line 33) 25726* INSN_FROM_TARGET_P: Flags. (line 38) 25727* insn_list: Insns. (line 530) 25728* insn_list and /i: Flags. (line 147) 25729* INSN_REFERENCES_ARE_DELAYED: Misc. (line 461) 25730* INSN_SETS_ARE_DELAYED: Misc. (line 450) 25731* INSN_UID: Insns. (line 23) 25732* insns: Insns. (line 6) 25733* insns, generating: RTL Template. (line 6) 25734* insns, recognizing: RTL Template. (line 6) 25735* instruction attributes: Insn Attributes. (line 6) 25736* instruction combination: Passes. (line 266) 25737* instruction latency time <1>: Comparison of the two descriptions. 25738 (line 6) 25739* instruction latency time <2>: Automaton pipeline description. 25740 (line 63) 25741* instruction latency time: Processor pipeline description. 25742 (line 6) 25743* instruction patterns: Patterns. (line 6) 25744* instruction recognizer: Passes. (line 450) 25745* instruction scheduling: Passes. (line 296) 25746* instruction splitting: Insn Splitting. (line 6) 25747* insv instruction pattern: Standard Names. (line 523) 25748* INT_TYPE_SIZE: Type Layout. (line 12) 25749* INTEGER_CST: Expression trees. (line 6) 25750* INTEGER_TYPE: Types. (line 6) 25751* INTEGRATE_THRESHOLD: Misc. (line 306) 25752* integrated: Flags. (line 297) 25753* integrated, in insn, call_insn, jump_insn, barrier, code_label, insn_list, const, and note: Flags. 25754 (line 147) 25755* integrated, in reg: Flags. (line 97) 25756* integrated, in symbol_ref: Flags. (line 227) 25757* Interdependence of Patterns: Dependent Patterns. (line 6) 25758* interfacing to GCC output: Interface. (line 6) 25759* interlock delays <1>: Comparison of the two descriptions. 25760 (line 6) 25761* interlock delays: Processor pipeline description. 25762 (line 6) 25763* INTMAX_TYPE: Type Layout. (line 164) 25764* introduction: Top. (line 6) 25765* INVOKE__main: Macros for Initialization. 25766 (line 51) 25767* ior: Arithmetic. (line 137) 25768* ior and attributes: Expressions. (line 50) 25769* ior, canonicalization of: Insn Canonicalizations. 25770 (line 48) 25771* iorM3 instruction pattern: Standard Names. (line 167) 25772* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 120) 25773* IS_COSTLY_DEPENDENCE: Scheduling. (line 240) 25774* jump: Flags. (line 310) 25775* jump bypassing: Passes. (line 223) 25776* jump instruction pattern: Standard Names. (line 605) 25777* jump instruction patterns: Jump Patterns. (line 6) 25778* jump instructions and set: Side Effects. (line 52) 25779* jump optimization: Passes. (line 139) 25780* jump threading: Passes. (line 165) 25781* jump, in call_insn: Flags. (line 186) 25782* jump, in insn: Flags. (line 182) 25783* jump, in mem: Flags. (line 73) 25784* JUMP_ALIGN: Alignment Output. (line 9) 25785* jump_insn: Insns. (line 74) 25786* jump_insn and /f: Flags. (line 120) 25787* jump_insn and /i: Flags. (line 147) 25788* jump_insn and /s: Flags. (line 38) 25789* jump_insn and /u: Flags. (line 24) 25790* jump_insn and /v: Flags. (line 33) 25791* JUMP_LABEL: Insns. (line 80) 25792* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 108) 25793* LABEL_ALIGN: Alignment Output. (line 52) 25794* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 22) 25795* LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. (line 30) 25796* LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 62) 25797* LABEL_ALT_ENTRY_P: Insns. (line 146) 25798* LABEL_DECL: Declarations. (line 6) 25799* LABEL_KIND: Insns. (line 146) 25800* LABEL_NUSES: Insns. (line 142) 25801* LABEL_OUTSIDE_LOOP_P: Flags. (line 48) 25802* LABEL_PRESERVE_P: Flags. (line 53) 25803* label_ref: Constants. (line 94) 25804* label_ref and /s: Flags. (line 48) 25805* label_ref and /v: Flags. (line 59) 25806* label_ref, RTL sharing: Sharing. (line 35) 25807* LABEL_REF_NONLOCAL_P: Flags. (line 59) 25808* LABEL_STMT: Function Bodies. (line 6) 25809* LABEL_STMT_LABEL: Function Bodies. (line 6) 25810* large return values: Aggregate Return. (line 6) 25811* LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 472) 25812* LAST_STACK_REG: Stack Registers. (line 27) 25813* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 25814* LD_FINI_SWITCH: Macros for Initialization. 25815 (line 29) 25816* LD_INIT_SWITCH: Macros for Initialization. 25817 (line 25) 25818* LDD_SUFFIX: Macros for Initialization. 25819 (line 121) 25820* le: Comparisons. (line 73) 25821* le and attributes: Expressions. (line 64) 25822* LE_EXPR: Expression trees. (line 6) 25823* leaf functions: Leaf Functions. (line 6) 25824* leaf_function_p: Standard Names. (line 676) 25825* LEAF_REG_REMAP: Leaf Functions. (line 39) 25826* LEAF_REGISTERS: Leaf Functions. (line 25) 25827* left rotate: Arithmetic. (line 160) 25828* left shift: Arithmetic. (line 147) 25829* LEGITIMATE_CONSTANT_P: Addressing Modes. (line 223) 25830* LEGITIMATE_PIC_OPERAND_P: PIC. (line 47) 25831* LEGITIMIZE_ADDRESS: Addressing Modes. (line 140) 25832* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 163) 25833* length: GTY Options. (line 43) 25834* less than: Comparisons. (line 65) 25835* less than or equal: Comparisons. (line 73) 25836* leu: Comparisons. (line 73) 25837* leu and attributes: Expressions. (line 64) 25838* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 25839* LIB_SPEC: Driver. (line 170) 25840* LIBCALL_VALUE: Scalar Return. (line 53) 25841* libgcc.a: Library Calls. (line 6) 25842* LIBGCC2_CFLAGS: Target Fragment. (line 8) 25843* LIBGCC2_WORDS_BIG_ENDIAN: Storage Layout. (line 36) 25844* LIBGCC_SPEC: Driver. (line 178) 25845* library subroutine names: Library Calls. (line 6) 25846* LIBRARY_PATH_ENV: Misc. (line 492) 25847* LIMIT_RELOAD_CLASS: Register Classes. (line 213) 25848* LINK_COMMAND_SPEC: Driver. (line 285) 25849* LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 295) 25850* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 281) 25851* LINK_LIBGCC_SPECIAL: Driver. (line 267) 25852* LINK_LIBGCC_SPECIAL_1: Driver. (line 274) 25853* LINK_SPEC: Driver. (line 163) 25854* linkage: Function Basics. (line 6) 25855* list: Containers. (line 6) 25856* lo_sum: Arithmetic. (line 18) 25857* load address instruction: Simple Constraints. (line 152) 25858* LOAD_EXTEND_OP: Misc. (line 94) 25859* load_multiple instruction pattern: Standard Names. (line 125) 25860* local register allocation: Passes. (line 322) 25861* LOCAL_ALIGNMENT: Storage Layout. (line 226) 25862* LOCAL_CLASS_P: Classes. (line 66) 25863* LOCAL_INCLUDE_DIR: Driver. (line 348) 25864* LOCAL_LABEL_PREFIX: Instruction Output. (line 125) 25865* LOCAL_REGNO: Register Basics. (line 112) 25866* LOG_LINKS: Insns. (line 286) 25867* logical-and, bitwise: Arithmetic. (line 132) 25868* logM2 instruction pattern: Standard Names. (line 266) 25869* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 65) 25870* LONG_LONG_TYPE_SIZE: Type Layout. (line 40) 25871* LONG_TYPE_SIZE: Type Layout. (line 22) 25872* longjmp and automatic variables: Interface. (line 52) 25873* loop optimization: Passes. (line 204) 25874* LOOP_ALIGN: Alignment Output. (line 35) 25875* LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 48) 25876* LOOP_EXPR: Expression trees. (line 6) 25877* looping instruction patterns: Looping Patterns. (line 6) 25878* LSHIFT_EXPR: Expression trees. (line 6) 25879* lshiftrt: Arithmetic. (line 155) 25880* lshiftrt and attributes: Expressions. (line 64) 25881* lshrM3 instruction pattern: Standard Names. (line 224) 25882* lt: Comparisons. (line 65) 25883* lt and attributes: Expressions. (line 64) 25884* LT_EXPR: Expression trees. (line 6) 25885* ltu: Comparisons. (line 65) 25886* m in constraint: Simple Constraints. (line 17) 25887* machine attributes: Target Attributes. (line 6) 25888* machine description macros: Target Macros. (line 6) 25889* machine descriptions: Machine Desc. (line 6) 25890* machine mode conversions: Conversions. (line 6) 25891* machine modes: Machine Modes. (line 6) 25892* machine specific constraints: Machine Constraints. 25893 (line 6) 25894* machine_mode: Condition Code. (line 155) 25895* macros, target description: Target Macros. (line 6) 25896* MAKE_DECL_ONE_ONLY: Label Output. (line 198) 25897* make_safe_from: Expander Definitions. 25898 (line 148) 25899* makefile fragment: Fragments. (line 6) 25900* makefile targets: Makefile. (line 6) 25901* marking roots: GGC Roots. (line 6) 25902* MASK_RETURN_ADDR: Exception Region Output. 25903 (line 29) 25904* match_dup <1>: define_peephole2. (line 28) 25905* match_dup: RTL Template. (line 94) 25906* match_dup and attributes: Insn Lengths. (line 16) 25907* match_insn: RTL Template. (line 244) 25908* match_insn2: RTL Template. (line 253) 25909* match_op_dup: RTL Template. (line 184) 25910* match_operand: RTL Template. (line 16) 25911* match_operand and attributes: Expressions. (line 55) 25912* match_operator: RTL Template. (line 116) 25913* match_par_dup: RTL Template. (line 240) 25914* match_parallel: RTL Template. (line 193) 25915* match_scratch <1>: define_peephole2. (line 28) 25916* match_scratch: RTL Template. (line 79) 25917* matching constraint: Simple Constraints. (line 130) 25918* matching operands: Output Template. (line 50) 25919* math library: Soft float library routines. 25920 (line 6) 25921* math, in RTL: Arithmetic. (line 6) 25922* MATH_LIBRARY: Misc. (line 485) 25923* matherr: Library Calls. (line 48) 25924* MAX_BITS_PER_WORD: Storage Layout. (line 61) 25925* MAX_CONDITIONAL_EXECUTE: Misc. (line 506) 25926* MAX_DFA_ISSUE_RATE: Scheduling. (line 283) 25927* MAX_FIXED_MODE_SIZE: Storage Layout. (line 350) 25928* MAX_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 70) 25929* MAX_LONG_TYPE_SIZE: Type Layout. (line 33) 25930* MAX_MOVE_MAX: Misc. (line 133) 25931* MAX_OFILE_ALIGNMENT: Storage Layout. (line 194) 25932* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 25933* MAX_WCHAR_TYPE_SIZE: Type Layout. (line 141) 25934* maxM3 instruction pattern: Standard Names. (line 171) 25935* MAYBE_REG_PARM_STACK_SPACE: Stack Arguments. (line 70) 25936* maybe_undef: GTY Options. (line 158) 25937* mcount: Profiling. (line 12) 25938* MD_ASM_CLOBBERS: Misc. (line 481) 25939* MD_CAN_REDIRECT_BRANCH: Misc. (line 599) 25940* MD_EXEC_PREFIX: Driver. (line 316) 25941* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 94) 25942* MD_HANDLE_UNWABI: Exception Handling. (line 112) 25943* MD_STARTFILE_PREFIX: Driver. (line 330) 25944* MD_STARTFILE_PREFIX_1: Driver. (line 336) 25945* mem: Regs and Memory. (line 249) 25946* mem and /c: Flags. (line 93) 25947* mem and /f: Flags. (line 79) 25948* mem and /j: Flags. (line 73) 25949* mem and /s: Flags. (line 64) 25950* mem and /u: Flags. (line 153) 25951* mem and /v: Flags. (line 88) 25952* mem, RTL sharing: Sharing. (line 40) 25953* MEM_ALIAS_SET: Special Accessors. (line 9) 25954* MEM_ALIGN: Special Accessors. (line 36) 25955* MEM_EXPR: Special Accessors. (line 20) 25956* MEM_IN_STRUCT_P: Flags. (line 64) 25957* MEM_KEEP_ALIAS_SET_P: Flags. (line 73) 25958* MEM_NOTRAP_P: Flags. (line 93) 25959* MEM_OFFSET: Special Accessors. (line 28) 25960* MEM_SCALAR_P: Flags. (line 79) 25961* MEM_SIZE: Special Accessors. (line 31) 25962* MEM_VOLATILE_P: Flags. (line 88) 25963* MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 328) 25964* memcpy, implicit usage: Library Calls. (line 66) 25965* memmove, implicit usage: Library Calls. (line 66) 25966* memory reference, nonoffsettable: Simple Constraints. (line 251) 25967* memory references in constraints: Simple Constraints. (line 17) 25968* MEMORY_MOVE_COST: Costs. (line 29) 25969* memset, implicit usage: Library Calls. (line 66) 25970* METHOD_TYPE: Types. (line 6) 25971* MIN_UNITS_PER_WORD: Storage Layout. (line 70) 25972* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 172) 25973* minM3 instruction pattern: Standard Names. (line 171) 25974* minus: Arithmetic. (line 27) 25975* minus and attributes: Expressions. (line 64) 25976* minus, canonicalization of: Insn Canonicalizations. 25977 (line 21) 25978* MINUS_EXPR: Expression trees. (line 6) 25979* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 25980* mod: Arithmetic. (line 113) 25981* mod and attributes: Expressions. (line 64) 25982* mode classes: Machine Modes. (line 134) 25983* mode switching: Mode Switching. (line 6) 25984* MODE_AFTER: Mode Switching. (line 49) 25985* MODE_BASE_REG_CLASS: Register Classes. (line 112) 25986* MODE_CC: Machine Modes. (line 163) 25987* MODE_COMPLEX_FLOAT: Machine Modes. (line 155) 25988* MODE_COMPLEX_INT: Machine Modes. (line 152) 25989* MODE_ENTRY: Mode Switching. (line 54) 25990* MODE_EXIT: Mode Switching. (line 60) 25991* MODE_FLOAT: Machine Modes. (line 148) 25992* MODE_FUNCTION: Machine Modes. (line 159) 25993* MODE_HAS_INFINITIES: Storage Layout. (line 420) 25994* MODE_HAS_NANS: Storage Layout. (line 410) 25995* MODE_HAS_SIGN_DEPENDENT_ROUNDING: Storage Layout. (line 442) 25996* MODE_HAS_SIGNED_ZEROS: Storage Layout. (line 426) 25997* MODE_INT: Machine Modes. (line 140) 25998* MODE_NEEDED: Mode Switching. (line 42) 25999* MODE_PARTIAL_INT: Machine Modes. (line 144) 26000* MODE_PRIORITY_TO_MODE: Mode Switching. (line 66) 26001* MODE_RANDOM: Machine Modes. (line 168) 26002* MODES_TIEABLE_P: Values in Registers. 26003 (line 92) 26004* modifiers in constraints: Modifiers. (line 6) 26005* MODIFY_EXPR: Expression trees. (line 6) 26006* MODIFY_JNI_METHOD_CALL: Misc. (line 642) 26007* MODIFY_TARGET_NAME: Driver. (line 357) 26008* modM3 instruction pattern: Standard Names. (line 167) 26009* MOVE_BY_PIECES_P: Costs. (line 104) 26010* MOVE_MAX: Misc. (line 128) 26011* MOVE_MAX_PIECES: Costs. (line 110) 26012* MOVE_RATIO: Costs. (line 91) 26013* movM instruction pattern: Standard Names. (line 11) 26014* movMODEcc instruction pattern: Standard Names. (line 533) 26015* movstrictM instruction pattern: Standard Names. (line 119) 26016* movstrM instruction pattern: Standard Names. (line 390) 26017* mulhisi3 instruction pattern: Standard Names. (line 178) 26018* mulM3 instruction pattern: Standard Names. (line 167) 26019* mulqihi3 instruction pattern: Standard Names. (line 182) 26020* mulsidi3 instruction pattern: Standard Names. (line 182) 26021* mult: Arithmetic. (line 84) 26022* mult and attributes: Expressions. (line 64) 26023* mult, canonicalization of: Insn Canonicalizations. 26024 (line 21) 26025* MULT_EXPR: Expression trees. (line 6) 26026* MULTILIB_DEFAULTS: Driver. (line 301) 26027* MULTILIB_DIRNAMES: Target Fragment. (line 64) 26028* MULTILIB_EXCEPTIONS: Target Fragment. (line 84) 26029* MULTILIB_EXTRA_OPTS: Target Fragment. (line 96) 26030* MULTILIB_MATCHES: Target Fragment. (line 77) 26031* MULTILIB_OPTIONS: Target Fragment. (line 44) 26032* multiple alternative constraints: Multi-Alternative. (line 6) 26033* MULTIPLE_SYMBOL_SPACES: Misc. (line 474) 26034* multiplication: Arithmetic. (line 84) 26035* MUST_PASS_IN_STACK: Register Arguments. (line 61) 26036* MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments. (line 52) 26037* MUST_USE_SJLJ_EXCEPTIONS: Exception Region Output. 26038 (line 49) 26039* n in constraint: Simple Constraints. (line 63) 26040* N_REG_CLASSES: Register Classes. (line 76) 26041* name: Identifiers. (line 6) 26042* named patterns and conditions: Patterns. (line 48) 26043* names, pattern: Standard Names. (line 6) 26044* namespace: Namespaces. (line 6) 26045* namespace, class, scope: Scopes. (line 6) 26046* NAMESPACE_DECL <1>: Declarations. (line 6) 26047* NAMESPACE_DECL: Namespaces. (line 6) 26048* ne: Comparisons. (line 53) 26049* ne and attributes: Expressions. (line 64) 26050* NE_EXPR: Expression trees. (line 6) 26051* nearbyintM2 instruction pattern: Standard Names. (line 325) 26052* neg: Arithmetic. (line 80) 26053* neg and attributes: Expressions. (line 64) 26054* neg, canonicalization of: Insn Canonicalizations. 26055 (line 21) 26056* NEGATE_EXPR: Expression trees. (line 6) 26057* negM2 instruction pattern: Standard Names. (line 228) 26058* nested functions, trampolines for: Trampolines. (line 6) 26059* next_cc0_user: Jump Patterns. (line 64) 26060* NEXT_INSN: Insns. (line 30) 26061* NEXT_OBJC_RUNTIME: Library Calls. (line 80) 26062* nil: RTL Objects. (line 73) 26063* NO_DBX_FUNCTION_END: DBX Hooks. (line 80) 26064* NO_DOLLAR_IN_LABEL: Misc. (line 429) 26065* NO_DOT_IN_LABEL: Misc. (line 435) 26066* NO_FUNCTION_CSE: Costs. (line 178) 26067* NO_IMPLICIT_EXTERN_C: Misc. (line 326) 26068* no_new_pseudos: Standard Names. (line 77) 26069* NO_PROFILE_COUNTERS: Profiling. (line 28) 26070* NO_RECURSIVE_FUNCTION_CSE: Costs. (line 182) 26071* NO_REGS: Register Classes. (line 17) 26072* NON_SAVING_SETJMP: Register Basics. (line 91) 26073* nondeterministic finite state automaton: Automaton pipeline description. 26074 (line 253) 26075* nonlocal_goto instruction pattern: Standard Names. (line 896) 26076* nonlocal_goto_receiver instruction pattern: Standard Names. 26077 (line 913) 26078* nonoffsettable memory reference: Simple Constraints. (line 251) 26079* nop instruction pattern: Standard Names. (line 709) 26080* NOP_EXPR: Expression trees. (line 6) 26081* not: Arithmetic. (line 128) 26082* not and attributes: Expressions. (line 50) 26083* not equal: Comparisons. (line 53) 26084* not, canonicalization of: Insn Canonicalizations. 26085 (line 21) 26086* note: Insns. (line 174) 26087* note and /i: Flags. (line 53) 26088* note and /v: Flags. (line 33) 26089* NOTE_INSN_BLOCK_BEG: Insns. (line 199) 26090* NOTE_INSN_BLOCK_END: Insns. (line 199) 26091* NOTE_INSN_DELETED: Insns. (line 189) 26092* NOTE_INSN_DELETED_LABEL: Insns. (line 194) 26093* NOTE_INSN_EH_REGION_BEG: Insns. (line 205) 26094* NOTE_INSN_EH_REGION_END: Insns. (line 205) 26095* NOTE_INSN_FUNCTION_END: Insns. (line 229) 26096* NOTE_INSN_LOOP_BEG: Insns. (line 213) 26097* NOTE_INSN_LOOP_CONT: Insns. (line 219) 26098* NOTE_INSN_LOOP_END: Insns. (line 213) 26099* NOTE_INSN_LOOP_VTOP: Insns. (line 223) 26100* NOTE_INSN_SETJMP: Insns. (line 235) 26101* NOTE_LINE_NUMBER: Insns. (line 174) 26102* NOTE_SOURCE_FILE: Insns. (line 174) 26103* NOTICE_UPDATE_CC: Condition Code. (line 33) 26104* NUM_MACHINE_MODES: Machine Modes. (line 181) 26105* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 26106* o in constraint: Simple Constraints. (line 21) 26107* OBJC_GEN_METHOD_LABEL: Label Output. (line 359) 26108* OBJECT_FORMAT_COFF: Macros for Initialization. 26109 (line 97) 26110* OFFSET_TYPE: Types. (line 6) 26111* offsettable address: Simple Constraints. (line 21) 26112* OImode: Machine Modes. (line 51) 26113* old pipeline description <1>: Comparison of the two descriptions. 26114 (line 6) 26115* old pipeline description: Old pipeline description. 26116 (line 6) 26117* one_cmplM2 instruction pattern: Standard Names. (line 369) 26118* operand access: Accessors. (line 6) 26119* operand constraints: Constraints. (line 6) 26120* operand substitution: Output Template. (line 6) 26121* operands: Patterns. (line 54) 26122* OPTIMIZATION_OPTIONS: Run-time Target. (line 201) 26123* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9) 26124* OPTION_DEFAULT_SPECS: Driver. (line 88) 26125* optional hardware or system features: Run-time Target. (line 54) 26126* options, directory search: Including Patterns. (line 44) 26127* order of register allocation: Allocation Order. (line 6) 26128* ORDER_REGS_FOR_LOCAL_ALLOC: Allocation Order. (line 23) 26129* Ordering of Patterns: Pattern Ordering. (line 6) 26130* ORIGINAL_REGNO: Special Accessors. (line 40) 26131* other register constraints: Simple Constraints. (line 161) 26132* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 98) 26133* OUTGOING_REGNO: Register Basics. (line 105) 26134* output of assembler code: File Framework. (line 6) 26135* output statements: Output Statement. (line 6) 26136* output templates: Output Template. (line 6) 26137* OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 39) 26138* output_asm_insn: Output Statement. (line 53) 26139* OUTPUT_QUOTED_STRING: File Framework. (line 76) 26140* OVERLOAD: Functions. (line 6) 26141* OVERRIDE_OPTIONS: Run-time Target. (line 191) 26142* OVL_CURRENT: Functions. (line 6) 26143* OVL_NEXT: Functions. (line 6) 26144* p in constraint: Simple Constraints. (line 152) 26145* PAD_VARARGS_DOWN: Register Arguments. (line 203) 26146* parallel: Side Effects. (line 197) 26147* param_is: GTY Options. (line 107) 26148* parameters, miscellaneous: Misc. (line 6) 26149* parameters, precompiled headers: PCH Target. (line 6) 26150* paramN_is: GTY Options. (line 119) 26151* parity: Arithmetic. (line 198) 26152* parityM2 instruction pattern: Standard Names. (line 363) 26153* PARM_BOUNDARY: Storage Layout. (line 134) 26154* PARM_DECL: Declarations. (line 6) 26155* PARSE_LDD_OUTPUT: Macros for Initialization. 26156 (line 126) 26157* parsing pass: Passes. (line 13) 26158* passes and files of the compiler: Passes. (line 6) 26159* passing arguments: Interface. (line 36) 26160* PATH_SEPARATOR: Filesystem. (line 31) 26161* PATTERN: Insns. (line 257) 26162* pattern conditions: Patterns. (line 44) 26163* pattern names: Standard Names. (line 6) 26164* Pattern Ordering: Pattern Ordering. (line 6) 26165* patterns: Patterns. (line 6) 26166* pc: Regs and Memory. (line 236) 26167* pc and attributes: Insn Lengths. (line 20) 26168* pc, RTL sharing: Sharing. (line 25) 26169* PC_REGNUM: Register Basics. (line 119) 26170* pc_rtx: Regs and Memory. (line 241) 26171* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 256) 26172* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 60) 26173* PDImode: Machine Modes. (line 40) 26174* peephole optimization: Passes. (line 409) 26175* peephole optimization, RTL representation: Side Effects. (line 231) 26176* peephole optimizer definitions: Peephole Definitions. 26177 (line 6) 26178* per-function data: Per-Function Data. (line 6) 26179* percent sign: Output Template. (line 6) 26180* PIC: PIC. (line 6) 26181* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26) 26182* PIC_OFFSET_TABLE_REGNUM: PIC. (line 16) 26183* pipeline hazard recognizer <1>: Comparison of the two descriptions. 26184 (line 6) 26185* pipeline hazard recognizer <2>: Automaton pipeline description. 26186 (line 10) 26187* pipeline hazard recognizer: Processor pipeline description. 26188 (line 6) 26189* plus: Arithmetic. (line 14) 26190* plus and attributes: Expressions. (line 64) 26191* plus, canonicalization of: Insn Canonicalizations. 26192 (line 21) 26193* PLUS_EXPR: Expression trees. (line 6) 26194* Pmode: Misc. (line 289) 26195* pointer: Types. (line 6) 26196* POINTER_SIZE: Storage Layout. (line 76) 26197* POINTER_TYPE: Types. (line 6) 26198* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 82) 26199* popcount: Arithmetic. (line 194) 26200* popcountM2 instruction pattern: Standard Names. (line 357) 26201* portability: Portability. (line 6) 26202* position independent code: PIC. (line 6) 26203* post_dec: Incdec. (line 25) 26204* post_inc: Incdec. (line 30) 26205* post_modify: Incdec. (line 33) 26206* POWI_MAX_MULTS: Misc. (line 690) 26207* powM3 instruction pattern: Standard Names. (line 274) 26208* pragma: Misc. (line 331) 26209* pre_dec: Incdec. (line 8) 26210* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 110) 26211* pre_inc: Incdec. (line 22) 26212* pre_modify: Incdec. (line 51) 26213* predefined macros: Run-time Target. (line 6) 26214* PREDICATE_CODES: Misc. (line 9) 26215* predication: Conditional Execution. 26216 (line 6) 26217* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42) 26218* PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 208) 26219* PREFERRED_RELOAD_CLASS: Register Classes. (line 181) 26220* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 148) 26221* prefetch: Side Effects. (line 305) 26222* prefetch instruction pattern: Standard Names. (line 1033) 26223* presence_set: Automaton pipeline description. 26224 (line 172) 26225* prev_active_insn: define_peephole. (line 60) 26226* prev_cc0_setter: Jump Patterns. (line 64) 26227* PREV_INSN: Insns. (line 26) 26228* PRINT_OPERAND: Instruction Output. (line 68) 26229* PRINT_OPERAND_ADDRESS: Instruction Output. (line 96) 26230* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 89) 26231* processor functional units <1>: Comparison of the two descriptions. 26232 (line 6) 26233* processor functional units <2>: Automaton pipeline description. 26234 (line 25) 26235* processor functional units: Processor pipeline description. 26236 (line 6) 26237* processor pipeline description: Processor pipeline description. 26238 (line 6) 26239* product: Arithmetic. (line 84) 26240* PROFILE_BEFORE_PROLOGUE: Profiling. (line 35) 26241* PROFILE_HOOK: Profiling. (line 23) 26242* profiling, code generation: Profiling. (line 6) 26243* program counter: Regs and Memory. (line 237) 26244* prologue: Function Entry. (line 6) 26245* prologue instruction pattern: Standard Names. (line 979) 26246* PROMOTE_FOR_CALL_ONLY: Storage Layout. (line 127) 26247* PROMOTE_MODE: Storage Layout. (line 92) 26248* pseudo registers: Regs and Memory. (line 9) 26249* PSImode: Machine Modes. (line 32) 26250* PTRDIFF_TYPE: Type Layout. (line 120) 26251* PTRMEM_CST: Expression trees. (line 6) 26252* PTRMEM_CST_CLASS: Expression trees. (line 6) 26253* PTRMEM_CST_MEMBER: Expression trees. (line 6) 26254* push address instruction: Simple Constraints. (line 152) 26255* PUSH_ARGS: Stack Arguments. (line 18) 26256* PUSH_ARGS_REVERSED: Stack Arguments. (line 26) 26257* push_reload: Addressing Modes. (line 187) 26258* PUSH_ROUNDING: Stack Arguments. (line 32) 26259* PUSH_ROUNDING, interaction with PREFERRED_STACK_BOUNDARY: Storage Layout. 26260 (line 159) 26261* pushM instruction pattern: Standard Names. (line 154) 26262* PUT_CODE: RTL Objects. (line 47) 26263* PUT_MODE: Machine Modes. (line 178) 26264* PUT_REG_NOTE_KIND: Insns. (line 323) 26265* PUT_SDB_: SDB and DWARF. (line 56) 26266* QCmode: Machine Modes. (line 111) 26267* QFmode: Machine Modes. (line 54) 26268* QImode: Machine Modes. (line 25) 26269* QImode, in insn: Insns. (line 241) 26270* qualified type: Types. (line 6) 26271* querying function unit reservations: Automaton pipeline description. 26272 (line 47) 26273* question mark: Multi-Alternative. (line 41) 26274* quotient: Arithmetic. (line 99) 26275* r in constraint: Simple Constraints. (line 54) 26276* RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 187) 26277* RDIV_EXPR: Expression trees. (line 6) 26278* READONLY_DATA_SECTION: Sections. (line 43) 26279* READONLY_DATA_SECTION_ASM_OP: Sections. (line 38) 26280* REAL_ARITHMETIC: Floating Point. (line 67) 26281* REAL_CST: Expression trees. (line 6) 26282* REAL_NM_FILE_NAME: Macros for Initialization. 26283 (line 111) 26284* REAL_TYPE: Types. (line 6) 26285* REAL_VALUE_ABS: Floating Point. (line 83) 26286* REAL_VALUE_ATOF: Floating Point. (line 51) 26287* REAL_VALUE_FIX: Floating Point. (line 42) 26288* REAL_VALUE_FROM_INT: Floating Point. (line 100) 26289* REAL_VALUE_ISINF: Floating Point. (line 60) 26290* REAL_VALUE_ISNAN: Floating Point. (line 63) 26291* REAL_VALUE_NEGATE: Floating Point. (line 80) 26292* REAL_VALUE_NEGATIVE: Floating Point. (line 57) 26293* REAL_VALUE_TO_INT: Floating Point. (line 94) 26294* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 138) 26295* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 139) 26296* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 137) 26297* REAL_VALUE_TRUNCATE: Floating Point. (line 87) 26298* REAL_VALUE_TYPE: Floating Point. (line 27) 26299* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 46) 26300* REAL_VALUES_EQUAL: Floating Point. (line 33) 26301* REAL_VALUES_LESS: Floating Point. (line 39) 26302* REALPART_EXPR: Expression trees. (line 6) 26303* recog_data.operand: Instruction Output. (line 39) 26304* recognizing insns: RTL Template. (line 6) 26305* RECORD_TYPE <1>: Classes. (line 6) 26306* RECORD_TYPE: Types. (line 6) 26307* reference: Types. (line 6) 26308* REFERENCE_TYPE: Types. (line 6) 26309* reg: Regs and Memory. (line 9) 26310* reg and /f: Flags. (line 107) 26311* reg and /i: Flags. (line 97) 26312* reg and /s: Flags. (line 102) 26313* reg and /u: Flags. (line 153) 26314* reg and /v: Flags. (line 111) 26315* reg, RTL sharing: Sharing. (line 17) 26316* REG_ALLOC_ORDER: Allocation Order. (line 9) 26317* REG_BR_PRED: Insns. (line 516) 26318* REG_BR_PROB: Insns. (line 510) 26319* REG_CC_SETTER: Insns. (line 485) 26320* REG_CC_USER: Insns. (line 485) 26321* REG_CLASS_CONTENTS: Register Classes. (line 86) 26322* reg_class_contents: Register Basics. (line 59) 26323* REG_CLASS_FROM_CONSTRAINT: Register Classes. (line 147) 26324* REG_CLASS_FROM_LETTER: Register Classes. (line 139) 26325* REG_CLASS_NAMES: Register Classes. (line 81) 26326* REG_DEAD: Insns. (line 334) 26327* REG_DEP_ANTI: Insns. (line 500) 26328* REG_DEP_OUTPUT: Insns. (line 503) 26329* REG_EQUAL: Insns. (line 390) 26330* REG_EQUIV: Insns. (line 390) 26331* REG_EXPR: Special Accessors. (line 46) 26332* REG_FRAME_RELATED_EXPR: Insns. (line 522) 26333* REG_FUNCTION_VALUE_P: Flags. (line 97) 26334* REG_INC: Insns. (line 350) 26335* REG_LABEL: Insns. (line 380) 26336* reg_label and /v: Flags. (line 59) 26337* REG_LIBCALL: Insns. (line 478) 26338* REG_LOOP_TEST_P: Flags. (line 102) 26339* REG_MODE_OK_FOR_BASE_P: Addressing Modes. (line 109) 26340* reg_names <1>: Instruction Output. (line 80) 26341* reg_names: Register Basics. (line 59) 26342* REG_NO_CONFLICT: Insns. (line 364) 26343* REG_NONNEG: Insns. (line 356) 26344* REG_NOTE_KIND: Insns. (line 323) 26345* REG_NOTES: Insns. (line 291) 26346* REG_OFFSET: Special Accessors. (line 50) 26347* REG_OK_FOR_BASE_P: Addressing Modes. (line 100) 26348* REG_OK_FOR_INDEX_P: Addressing Modes. (line 117) 26349* REG_OK_STRICT: Addressing Modes. (line 67) 26350* REG_PARM_STACK_SPACE: Stack Arguments. (line 56) 26351* REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments. 26352 (line 52) 26353* REG_POINTER: Flags. (line 107) 26354* REG_RETVAL: Insns. (line 462) 26355* REG_UNUSED: Insns. (line 343) 26356* REG_USERVAR_P: Flags. (line 111) 26357* register allocation: Passes. (line 312) 26358* register allocation order: Allocation Order. (line 6) 26359* register class definitions: Register Classes. (line 6) 26360* register class preference constraints: Class Preferences. (line 6) 26361* register class preference pass: Passes. (line 318) 26362* register movement: Passes. (line 286) 26363* register pairs: Values in Registers. 26364 (line 42) 26365* Register Transfer Language (RTL): RTL. (line 6) 26366* register usage: Registers. (line 6) 26367* register use analysis: Passes. (line 161) 26368* register-to-stack conversion: Passes. (line 400) 26369* REGISTER_MOVE_COST: Costs. (line 10) 26370* REGISTER_NAMES: Instruction Output. (line 9) 26371* register_operand: RTL Template. (line 62) 26372* REGISTER_PREFIX: Instruction Output. (line 124) 26373* REGISTER_TARGET_PRAGMAS: Misc. (line 332) 26374* registers arguments: Register Arguments. (line 6) 26375* registers in constraints: Simple Constraints. (line 54) 26376* REGMODE_NATURAL_SIZE: Values in Registers. 26377 (line 23) 26378* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 158) 26379* REGNO_OK_FOR_BASE_P: Register Classes. (line 152) 26380* REGNO_OK_FOR_INDEX_P: Register Classes. (line 166) 26381* REGNO_REG_CLASS: Register Classes. (line 101) 26382* regs_ever_live: Function Entry. (line 21) 26383* regular expressions <1>: Automaton pipeline description. 26384 (line 63) 26385* regular expressions: Processor pipeline description. 26386 (line 6) 26387* relative costs: Costs. (line 6) 26388* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 311) 26389* reload pass: Regs and Memory. (line 148) 26390* reload_completed: Standard Names. (line 676) 26391* reload_in instruction pattern: Standard Names. (line 101) 26392* reload_in_progress: Standard Names. (line 57) 26393* reload_out instruction pattern: Standard Names. (line 101) 26394* reloading: Passes. (line 344) 26395* remainder: Arithmetic. (line 113) 26396* reorder: GTY Options. (line 175) 26397* reordering, block: Passes. (line 372) 26398* representation of RTL: RTL. (line 6) 26399* reservation delays: Processor pipeline description. 26400 (line 6) 26401* rest_of_compilation: Passes. (line 22) 26402* rest_of_decl_compilation: Passes. (line 22) 26403* restore_stack_block instruction pattern: Standard Names. (line 815) 26404* restore_stack_function instruction pattern: Standard Names. 26405 (line 815) 26406* restore_stack_nonlocal instruction pattern: Standard Names. 26407 (line 815) 26408* RESULT_DECL: Declarations. (line 6) 26409* return: Side Effects. (line 68) 26410* return instruction pattern: Standard Names. (line 663) 26411* return values in registers: Scalar Return. (line 6) 26412* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 119) 26413* RETURN_ADDR_OFFSET: Exception Handling. (line 60) 26414* RETURN_ADDR_RTX: Frame Layout. (line 108) 26415* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 51) 26416* RETURN_EXPR: Function Bodies. (line 6) 26417* RETURN_INIT: Function Bodies. (line 6) 26418* RETURN_POPS_ARGS: Stack Arguments. (line 115) 26419* RETURN_STMT: Function Bodies. (line 6) 26420* returning aggregate values: Aggregate Return. (line 6) 26421* returning structures and unions: Interface. (line 10) 26422* REVERSE_CONDEXEC_PREDICATES_P: Condition Code. (line 129) 26423* REVERSE_CONDITION: Condition Code. (line 116) 26424* REVERSIBLE_CC_MODE: Condition Code. (line 102) 26425* right rotate: Arithmetic. (line 160) 26426* right shift: Arithmetic. (line 155) 26427* RISC <1>: Automaton pipeline description. 26428 (line 172) 26429* RISC: Processor pipeline description. 26430 (line 6) 26431* roots, marking: GGC Roots. (line 6) 26432* rotate: Arithmetic. (line 160) 26433* rotatert: Arithmetic. (line 160) 26434* rotlM3 instruction pattern: Standard Names. (line 224) 26435* rotrM3 instruction pattern: Standard Names. (line 224) 26436* ROUND_TOWARDS_ZERO: Storage Layout. (line 451) 26437* ROUND_TYPE_ALIGN: Storage Layout. (line 341) 26438* roundM2 instruction pattern: Standard Names. (line 309) 26439* RSHIFT_EXPR: Expression trees. (line 6) 26440* RTL addition: Arithmetic. (line 14) 26441* RTL addition with signed saturation: Arithmetic. (line 30) 26442* RTL addition with unsigned saturation: Arithmetic. (line 33) 26443* RTL classes: RTL Classes. (line 6) 26444* RTL comparison: Arithmetic. (line 42) 26445* RTL comparison operations: Comparisons. (line 6) 26446* RTL constant expression types: Constants. (line 6) 26447* RTL constants: Constants. (line 6) 26448* RTL declarations: RTL Declarations. (line 6) 26449* RTL difference: Arithmetic. (line 27) 26450* RTL expression: RTL Objects. (line 6) 26451* RTL expressions for arithmetic: Arithmetic. (line 6) 26452* RTL format: RTL Classes. (line 63) 26453* RTL format characters: RTL Classes. (line 68) 26454* RTL function-call insns: Calls. (line 6) 26455* RTL generation: Passes. (line 83) 26456* RTL insn template: RTL Template. (line 6) 26457* RTL integers: RTL Objects. (line 6) 26458* RTL memory expressions: Regs and Memory. (line 6) 26459* RTL object types: RTL Objects. (line 6) 26460* RTL postdecrement: Incdec. (line 6) 26461* RTL postincrement: Incdec. (line 6) 26462* RTL predecrement: Incdec. (line 6) 26463* RTL preincrement: Incdec. (line 6) 26464* RTL register expressions: Regs and Memory. (line 6) 26465* RTL representation: RTL. (line 6) 26466* RTL side effect expressions: Side Effects. (line 6) 26467* RTL strings: RTL Objects. (line 6) 26468* RTL structure sharing assumptions: Sharing. (line 6) 26469* RTL subtraction: Arithmetic. (line 27) 26470* RTL sum: Arithmetic. (line 14) 26471* RTL vectors: RTL Objects. (line 6) 26472* RTX (See RTL): RTL Objects. (line 6) 26473* RTX codes, classes of: RTL Classes. (line 6) 26474* RTX_FRAME_RELATED_P: Flags. (line 120) 26475* RTX_INTEGRATED_P: Flags. (line 147) 26476* RTX_UNCHANGING_P: Flags. (line 153) 26477* run-time conventions: Interface. (line 6) 26478* run-time target specification: Run-time Target. (line 6) 26479* s in constraint: Simple Constraints. (line 90) 26480* same_type_p: Types. (line 103) 26481* save_stack_block instruction pattern: Standard Names. (line 815) 26482* save_stack_function instruction pattern: Standard Names. (line 815) 26483* save_stack_nonlocal instruction pattern: Standard Names. (line 815) 26484* scalars, returned as values: Scalar Return. (line 6) 26485* SCHED_GROUP_P: Flags. (line 173) 26486* scheduling, delayed branch: Passes. (line 384) 26487* scheduling, instruction: Passes. (line 296) 26488* SCmode: Machine Modes. (line 111) 26489* sCOND instruction pattern: Standard Names. (line 553) 26490* SCOPE_BEGIN_P: Function Bodies. (line 6) 26491* SCOPE_END_P: Function Bodies. (line 6) 26492* SCOPE_NULLIFIED_P: Function Bodies. (line 6) 26493* SCOPE_STMT: Function Bodies. (line 6) 26494* scratch: Regs and Memory. (line 173) 26495* scratch operands: Regs and Memory. (line 173) 26496* scratch, RTL sharing: Sharing. (line 35) 26497* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 79) 26498* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 74) 26499* SDB_DEBUGGING_INFO: SDB and DWARF. (line 9) 26500* SDB_DELIM: SDB and DWARF. (line 62) 26501* SDB_GENERATE_FAKE: SDB and DWARF. (line 69) 26502* search options: Including Patterns. (line 44) 26503* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 230) 26504* SECONDARY_MEMORY_NEEDED: Register Classes. (line 292) 26505* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 311) 26506* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 302) 26507* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 231) 26508* SECONDARY_RELOAD_CLASS: Register Classes. (line 229) 26509* SELECT_CC_MODE: Condition Code. (line 68) 26510* sequence: Side Effects. (line 247) 26511* set: Side Effects. (line 15) 26512* set and /f: Flags. (line 120) 26513* SET_ASM_OP: Label Output. (line 334) 26514* set_attr: Tagging Insns. (line 31) 26515* set_attr_alternative: Tagging Insns. (line 49) 26516* SET_DEST: Side Effects. (line 65) 26517* SET_IS_RETURN_P: Flags. (line 182) 26518* SET_LABEL_KIND: Insns. (line 146) 26519* set_optab_libfunc: Library Calls. (line 15) 26520* SET_SRC: Side Effects. (line 65) 26521* SETUP_FRAME_ADDRESSES: Frame Layout. (line 93) 26522* SFmode: Machine Modes. (line 66) 26523* SHARED_SECTION_ASM_OP: Sections. (line 53) 26524* sharing of RTL components: Sharing. (line 6) 26525* shift: Arithmetic. (line 147) 26526* SHIFT_COUNT_TRUNCATED: Misc. (line 140) 26527* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 119) 26528* SHORT_TYPE_SIZE: Type Layout. (line 16) 26529* sibcall_epilogue instruction pattern: Standard Names. (line 1005) 26530* sibling call optimization: Passes. (line 128) 26531* SIBLING_CALL_P: Flags. (line 186) 26532* sign_extend: Conversions. (line 24) 26533* sign_extract: Bit-Fields. (line 11) 26534* sign_extract, canonicalization of: Insn Canonicalizations. 26535 (line 87) 26536* signed division: Arithmetic. (line 99) 26537* signed maximum: Arithmetic. (line 118) 26538* signed minimum: Arithmetic. (line 118) 26539* SImode: Machine Modes. (line 37) 26540* simple constraints: Simple Constraints. (line 6) 26541* simplifications, arithmetic: Passes. (line 79) 26542* sinM2 instruction pattern: Standard Names. (line 250) 26543* SIZE_ASM_OP: Label Output. (line 17) 26544* SIZE_TYPE: Type Layout. (line 104) 26545* skip: GTY Options. (line 70) 26546* SLOW_BYTE_ACCESS: Costs. (line 60) 26547* SLOW_UNALIGNED_ACCESS: Costs. (line 75) 26548* SMALL_ARG_MAX: Host Misc. (line 41) 26549* SMALL_REGISTER_CLASSES: Register Classes. (line 334) 26550* smax: Arithmetic. (line 118) 26551* smaxM3 instruction pattern: Standard Names. (line 167) 26552* smin: Arithmetic. (line 118) 26553* sminM3 instruction pattern: Standard Names. (line 167) 26554* smulM3_highpart instruction pattern: Standard Names. (line 189) 26555* soft float library: Soft float library routines. 26556 (line 6) 26557* special: GTY Options. (line 193) 26558* SPECIAL_MODE_PREDICATES: Misc. (line 34) 26559* SPECS: Target Fragment. (line 103) 26560* speed of instructions: Costs. (line 6) 26561* splitting instructions: Insn Splitting. (line 6) 26562* sqrt: Arithmetic. (line 168) 26563* sqrtM2 instruction pattern: Standard Names. (line 234) 26564* square root: Arithmetic. (line 168) 26565* ss_minus: Arithmetic. (line 36) 26566* ss_plus: Arithmetic. (line 30) 26567* ss_truncate: Conversions. (line 44) 26568* stack arguments: Stack Arguments. (line 6) 26569* stack frame layout: Frame Layout. (line 6) 26570* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48) 26571* STACK_BOUNDARY: Storage Layout. (line 140) 26572* STACK_CHECK_BUILTIN: Stack Checking. (line 29) 26573* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 64) 26574* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 55) 26575* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 71) 26576* STACK_CHECK_PROBE_INTERVAL: Stack Checking. (line 37) 26577* STACK_CHECK_PROBE_LOAD: Stack Checking. (line 44) 26578* STACK_CHECK_PROTECT: Stack Checking. (line 50) 26579* STACK_DYNAMIC_OFFSET: Frame Layout. (line 75) 26580* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 26581 (line 83) 26582* STACK_GROWS_DOWNWARD: Frame Layout. (line 9) 26583* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 106) 26584* STACK_POINTER_OFFSET: Frame Layout. (line 58) 26585* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 26586 (line 93) 26587* STACK_POINTER_REGNUM: Frame Registers. (line 9) 26588* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 26589 (line 83) 26590* stack_pointer_rtx: Frame Registers. (line 85) 26591* STACK_PUSH_CODE: Frame Layout. (line 17) 26592* STACK_REGS: Stack Registers. (line 20) 26593* STACK_SAVEAREA_MODE: Storage Layout. (line 362) 26594* STACK_SIZE_MODE: Storage Layout. (line 374) 26595* standard pattern names: Standard Names. (line 6) 26596* STANDARD_INCLUDE_COMPONENT: Driver. (line 397) 26597* STANDARD_INCLUDE_DIR: Driver. (line 389) 26598* STANDARD_STARTFILE_PREFIX: Driver. (line 323) 26599* STARTFILE_SPEC: Driver. (line 187) 26600* STARTING_FRAME_OFFSET: Frame Layout. (line 39) 26601* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 26602 (line 74) 26603* statements: Function Bodies. (line 6) 26604* STATIC_CHAIN: Frame Registers. (line 77) 26605* STATIC_CHAIN_INCOMING: Frame Registers. (line 78) 26606* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 64) 26607* STATIC_CHAIN_REGNUM: Frame Registers. (line 63) 26608* stdarg.h and register arguments: Register Arguments. (line 47) 26609* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 315) 26610* STMT_EXPR: Expression trees. (line 6) 26611* STMT_IS_FULL_EXPR_P: Function Bodies. (line 35) 26612* STMT_LINENO: Function Bodies. (line 23) 26613* storage layout: Storage Layout. (line 6) 26614* STORE_BY_PIECES_P: Costs. (line 130) 26615* STORE_FLAG_VALUE: Misc. (line 179) 26616* store_multiple instruction pattern: Standard Names. (line 148) 26617* strcpy: Storage Layout. (line 207) 26618* strength-reduction: Passes. (line 204) 26619* STRICT_ALIGNMENT: Storage Layout. (line 251) 26620* strict_low_part: RTL Declarations. (line 9) 26621* strict_memory_address_p: Addressing Modes. (line 197) 26622* STRING_CST: Expression trees. (line 6) 26623* STRING_POOL_ADDRESS_P: Flags. (line 190) 26624* strlenM instruction pattern: Standard Names. (line 452) 26625* structure value address: Aggregate Return. (line 6) 26626* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 243) 26627* structures, returning: Interface. (line 10) 26628* subM3 instruction pattern: Standard Names. (line 167) 26629* SUBOBJECT: Function Bodies. (line 6) 26630* SUBOBJECT_CLEANUP: Function Bodies. (line 6) 26631* subreg: Regs and Memory. (line 97) 26632* subreg and /s: Flags. (line 212) 26633* subreg and /u: Flags. (line 205) 26634* subreg and /u and /v: Flags. (line 195) 26635* subreg, in strict_low_part: RTL Declarations. (line 9) 26636* subreg, special reload handling: Regs and Memory. (line 148) 26637* SUBREG_BYTE: Regs and Memory. (line 169) 26638* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 195) 26639* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 205) 26640* SUBREG_PROMOTED_VAR_P: Flags. (line 212) 26641* SUBREG_REG: Regs and Memory. (line 169) 26642* SUCCESS_EXIT_CODE: Host Misc. (line 12) 26643* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 26644 (line 58) 26645* SUPPORTS_ONE_ONLY: Label Output. (line 207) 26646* SUPPORTS_WEAK: Label Output. (line 188) 26647* SWITCH_BODY: Function Bodies. (line 6) 26648* SWITCH_COND: Function Bodies. (line 6) 26649* SWITCH_CURTAILS_COMPILATION: Driver. (line 33) 26650* SWITCH_STMT: Function Bodies. (line 6) 26651* SWITCH_TAKES_ARG: Driver. (line 9) 26652* SWITCHES_NEED_SPACES: Driver. (line 47) 26653* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 80) 26654* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 73) 26655* SYMBOL_FLAG_LOCAL: Special Accessors. (line 76) 26656* SYMBOL_FLAG_SMALL: Special Accessors. (line 85) 26657* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 89) 26658* symbol_ref: Constants. (line 84) 26659* symbol_ref and /f: Flags. (line 190) 26660* symbol_ref and /i: Flags. (line 227) 26661* symbol_ref and /u: Flags. (line 10) 26662* symbol_ref and /v: Flags. (line 231) 26663* symbol_ref, RTL sharing: Sharing. (line 20) 26664* SYMBOL_REF_DECL: Special Accessors. (line 55) 26665* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 80) 26666* SYMBOL_REF_FLAG: Flags. (line 231) 26667* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 181) 26668* SYMBOL_REF_FLAGS: Special Accessors. (line 67) 26669* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 73) 26670* SYMBOL_REF_LOCAL_P: Special Accessors. (line 76) 26671* SYMBOL_REF_SMALL_P: Special Accessors. (line 85) 26672* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 89) 26673* SYMBOL_REF_USED: Flags. (line 222) 26674* SYMBOL_REF_WEAK: Flags. (line 227) 26675* symbolic label: Sharing. (line 20) 26676* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 216) 26677* SYSROOT_SUFFIX_SPEC: Driver. (line 211) 26678* SYSTEM_INCLUDE_DIR: Driver. (line 380) 26679* t-TARGET: Target Fragment. (line 6) 26680* tablejump instruction pattern: Standard Names. (line 743) 26681* tag: GTY Options. (line 75) 26682* tagging insns: Tagging Insns. (line 6) 26683* tail calls: Tail Calls. (line 6) 26684* tail recursion optimization: Passes. (line 92) 26685* target attributes: Target Attributes. (line 6) 26686* target description macros: Target Macros. (line 6) 26687* target functions: Target Structure. (line 6) 26688* target hooks: Target Structure. (line 6) 26689* target makefile fragment: Target Fragment. (line 6) 26690* target specifications: Run-time Target. (line 6) 26691* target-parameter-dependent code: Passes. (line 86) 26692* TARGET_: Run-time Target. (line 55) 26693* TARGET_ADDRESS_COST: Costs. (line 212) 26694* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10) 26695* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8) 26696* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 26697* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11) 26698* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 219) 26699* TARGET_ASM_BYTE_OP: Data Output. (line 7) 26700* TARGET_ASM_CLOSE_PAREN: Data Output. (line 128) 26701* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 26702 (line 69) 26703* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 26704 (line 83) 26705* TARGET_ASM_EH_FRAME_SECTION: Exception Region Output. 26706 (line 72) 26707* TARGET_ASM_EXCEPTION_SECTION: Exception Region Output. 26708 (line 64) 26709* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 235) 26710* TARGET_ASM_FILE_END: File Framework. (line 37) 26711* TARGET_ASM_FILE_START: File Framework. (line 9) 26712* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17) 26713* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31) 26714* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61) 26715* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55) 26716* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68) 26717* TARGET_ASM_FUNCTION_EPILOGUE and trampolines: Trampolines. (line 71) 26718* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11) 26719* TARGET_ASM_FUNCTION_PROLOGUE and trampolines: Trampolines. (line 71) 26720* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 159) 26721* TARGET_ASM_INTEGER: Data Output. (line 27) 26722* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 265) 26723* TARGET_ASM_NAMED_SECTION: File Framework. (line 99) 26724* TARGET_ASM_OPEN_PAREN: Data Output. (line 127) 26725* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 199) 26726* TARGET_ASM_OUTPUT_MI_VCALL_THUNK: Function Entry. (line 235) 26727* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 144) 26728* TARGET_ASM_SELECT_SECTION: Sections. (line 118) 26729* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14) 26730* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12) 26731* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13) 26732* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15) 26733* TARGET_ASM_UNIQUE_SECTION: Sections. (line 131) 26734* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11) 26735* TARGET_BELL: Escape Sequences. (line 11) 26736* TARGET_BINDS_LOCAL_P: Sections. (line 206) 26737* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 676) 26738* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 668) 26739* TARGET_C99_FUNCTIONS: Library Calls. (line 72) 26740* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 655) 26741* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 19) 26742* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9) 26743* TARGET_CR: Escape Sequences. (line 11) 26744* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 47) 26745* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 26746 (line 85) 26747* TARGET_EDOM: Library Calls. (line 49) 26748* TARGET_ENCODE_SECTION_INFO: Sections. (line 157) 26749* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 26750 (line 91) 26751* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 100) 26752* TARGET_ESC: Escape Sequences. (line 11) 26753* TARGET_EXECUTABLE_SUFFIX: Misc. (line 629) 26754* TARGET_EXPAND_BUILTIN: Misc. (line 590) 26755* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 92) 26756* TARGET_FF: Escape Sequences. (line 11) 26757* TARGET_FIXED_CONDITION_CODE_REGS: Condition Code. (line 140) 26758* target_flags: Run-time Target. (line 52) 26759* TARGET_FLOAT_FORMAT: Storage Layout. (line 383) 26760* TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25) 26761* TARGET_FLT_EVAL_METHOD: Type Layout. (line 77) 26762* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 69) 26763* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8) 26764* TARGET_HAS_F_SETLKW: Misc. (line 499) 26765* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 26766 (line 64) 26767* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 109) 26768* TARGET_IN_SMALL_DATA_P: Sections. (line 198) 26769* TARGET_INIT_BUILTINS: Misc. (line 573) 26770* TARGET_INIT_LIBFUNCS: Library Calls. (line 16) 26771* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 56) 26772* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 558) 26773* TARGET_MANGLE_FUNDAMENTAL_TYPE: Storage Layout. (line 518) 26774* TARGET_MEM_FUNCTIONS: Library Calls. (line 67) 26775* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 39) 26776* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 31) 26777* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 491) 26778* TARGET_NEWLINE: Escape Sequences. (line 11) 26779* TARGET_OBJECT_SUFFIX: Misc. (line 624) 26780* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46) 26781* TARGET_OPTION_TRANSLATE_TABLE: Driver. (line 53) 26782* TARGET_OPTIONS: Run-time Target. (line 115) 26783* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42) 26784* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 152) 26785* TARGET_PROMOTE_FUNCTION_ARGS: Storage Layout. (line 115) 26786* TARGET_PROMOTE_FUNCTION_RETURN: Storage Layout. (line 119) 26787* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11) 26788* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 186) 26789* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 16) 26790* TARGET_RETURN_IN_MSB: Scalar Return. (line 90) 26791* TARGET_RTX_COSTS: Costs. (line 193) 26792* TARGET_SCHED_ADJUST_COST: Scheduling. (line 40) 26793* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 55) 26794* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 92) 26795* TARGET_SCHED_DFA_BUBBLE: Scheduling. (line 230) 26796* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 193) 26797* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 146) 26798* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 134) 26799* TARGET_SCHED_FINISH: Scheduling. (line 112) 26800* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 26801 (line 156) 26802* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 26803 (line 184) 26804* TARGET_SCHED_INIT: Scheduling. (line 102) 26805* TARGET_SCHED_INIT_DFA_BUBBLES: Scheduling. (line 206) 26806* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 151) 26807* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 143) 26808* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12) 26809* TARGET_SCHED_REORDER: Scheduling. (line 63) 26810* TARGET_SCHED_REORDER2: Scheduling. (line 80) 26811* TARGET_SCHED_USE_DFA_PIPELINE_INTERFACE: Scheduling. (line 120) 26812* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 27) 26813* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 114) 26814* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 26) 26815* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 101) 26816* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 234) 26817* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 137) 26818* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 26819* TARGET_SWITCHES: Run-time Target. (line 79) 26820* TARGET_TAB: Escape Sequences. (line 11) 26821* TARGET_VECTOR_OPAQUE_P: Storage Layout. (line 484) 26822* TARGET_VERSION: Run-time Target. (line 178) 26823* TARGET_VT: Escape Sequences. (line 11) 26824* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 239) 26825* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 233) 26826* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 222) 26827* targetm: Target Structure. (line 7) 26828* targets, makefile: Makefile. (line 6) 26829* TCmode: Machine Modes. (line 111) 26830* TEMPLATE_DECL: Declarations. (line 6) 26831* termination routines: Initialization. (line 6) 26832* text_section: Sections. (line 101) 26833* TEXT_SECTION_ASM_OP: Sections. (line 18) 26834* TFmode: Machine Modes. (line 84) 26835* THEN_CLAUSE: Function Bodies. (line 6) 26836* THREAD_MODEL_SPEC: Driver. (line 202) 26837* THROW_EXPR: Expression trees. (line 6) 26838* THUNK_DECL: Declarations. (line 6) 26839* THUNK_DELTA: Declarations. (line 6) 26840* TImode: Machine Modes. (line 48) 26841* TImode, in insn: Insns. (line 241) 26842* tm.h macros: Target Macros. (line 6) 26843* top level of compiler: Passes. (line 6) 26844* TQFmode: Machine Modes. (line 62) 26845* TRADITIONAL_PIPELINE_INTERFACE: Scheduling. (line 267) 26846* TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 63) 26847* TRAMPOLINE_ALIGNMENT: Trampolines. (line 50) 26848* TRAMPOLINE_SECTION: Trampolines. (line 40) 26849* TRAMPOLINE_SIZE: Trampolines. (line 46) 26850* TRAMPOLINE_TEMPLATE: Trampolines. (line 29) 26851* trampolines for nested functions: Trampolines. (line 6) 26852* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 125) 26853* trap instruction pattern: Standard Names. (line 1015) 26854* tree <1>: Macros and Functions. 26855 (line 6) 26856* tree: Tree overview. (line 6) 26857* Tree optimization: Passes. (line 70) 26858* TREE_CODE: Tree overview. (line 6) 26859* tree_int_cst_equal: Expression trees. (line 6) 26860* TREE_INT_CST_HIGH: Expression trees. (line 6) 26861* TREE_INT_CST_LOW: Expression trees. (line 6) 26862* tree_int_cst_lt: Expression trees. (line 6) 26863* TREE_LIST: Containers. (line 6) 26864* TREE_OPERAND: Expression trees. (line 6) 26865* TREE_PUBLIC: Function Basics. (line 6) 26866* TREE_PURPOSE: Containers. (line 6) 26867* TREE_STRING_LENGTH: Expression trees. (line 6) 26868* TREE_STRING_POINTER: Expression trees. (line 6) 26869* TREE_TYPE <1>: Expression trees. (line 17) 26870* TREE_TYPE <2>: Function Basics. (line 164) 26871* TREE_TYPE <3>: Declarations. (line 16) 26872* TREE_TYPE: Types. (line 6) 26873* TREE_VALUE: Containers. (line 6) 26874* TREE_VEC: Containers. (line 6) 26875* TREE_VEC_ELT: Containers. (line 6) 26876* TREE_VEC_LENGTH: Containers. (line 6) 26877* TREE_VIA_PRIVATE: Classes. (line 6) 26878* TREE_VIA_PROTECTED: Classes. (line 6) 26879* TREE_VIA_PUBLIC: Classes. (line 6) 26880* Trees: Trees. (line 6) 26881* TRULY_NOOP_TRUNCATION: Misc. (line 166) 26882* TRUNC_DIV_EXPR: Expression trees. (line 6) 26883* TRUNC_MOD_EXPR: Expression trees. (line 6) 26884* truncate: Conversions. (line 39) 26885* truncM2 instruction pattern: Standard Names. (line 301) 26886* truncMN2 instruction pattern: Standard Names. (line 492) 26887* TRUTH_AND_EXPR: Expression trees. (line 6) 26888* TRUTH_ANDIF_EXPR: Expression trees. (line 6) 26889* TRUTH_NOT_EXPR: Expression trees. (line 6) 26890* TRUTH_OR_EXPR: Expression trees. (line 6) 26891* TRUTH_ORIF_EXPR: Expression trees. (line 6) 26892* TRUTH_XOR_EXPR: Expression trees. (line 6) 26893* TRY_BLOCK: Function Bodies. (line 6) 26894* TRY_HANDLERS: Function Bodies. (line 6) 26895* TRY_STMTS: Function Bodies. (line 6) 26896* tstM instruction pattern: Standard Names. (line 379) 26897* type: Types. (line 6) 26898* type declaration: Declarations. (line 6) 26899* TYPE_ALIGN: Types. (line 6) 26900* TYPE_ARG_TYPES: Types. (line 6) 26901* TYPE_ASM_OP: Label Output. (line 49) 26902* TYPE_ATTRIBUTES: Attributes. (line 25) 26903* TYPE_BINFO: Classes. (line 6) 26904* TYPE_BUILT_IN: Types. (line 84) 26905* TYPE_CONTEXT: Types. (line 6) 26906* TYPE_DECL: Declarations. (line 6) 26907* TYPE_FIELDS <1>: Classes. (line 6) 26908* TYPE_FIELDS: Types. (line 6) 26909* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 89) 26910* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 74) 26911* TYPE_HAS_MUTABLE_P: Classes. (line 79) 26912* TYPE_HAS_NEW_OPERATOR: Classes. (line 86) 26913* TYPE_MAIN_VARIANT: Types. (line 6) 26914* TYPE_MAX_VALUE: Types. (line 6) 26915* TYPE_METHOD_BASETYPE: Types. (line 6) 26916* TYPE_METHODS: Classes. (line 6) 26917* TYPE_MIN_VALUE: Types. (line 6) 26918* TYPE_NAME: Types. (line 6) 26919* TYPE_NOTHROW_P: Function Basics. (line 173) 26920* TYPE_OFFSET_BASETYPE: Types. (line 6) 26921* TYPE_OPERAND_FMT: Label Output. (line 60) 26922* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 97) 26923* TYPE_OVERLOADS_ARROW: Classes. (line 100) 26924* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 93) 26925* TYPE_POLYMORPHIC_P: Classes. (line 70) 26926* TYPE_PRECISION: Types. (line 6) 26927* TYPE_PTR_P: Types. (line 90) 26928* TYPE_PTRFN_P: Types. (line 94) 26929* TYPE_PTRMEM_P: Types. (line 6) 26930* TYPE_PTROB_P: Types. (line 97) 26931* TYPE_PTROBV_P: Types. (line 6) 26932* TYPE_QUAL_CONST: Types. (line 6) 26933* TYPE_QUAL_RESTRICT: Types. (line 6) 26934* TYPE_QUAL_VOLATILE: Types. (line 6) 26935* TYPE_RAISES_EXCEPTIONS: Function Basics. (line 168) 26936* TYPE_SIZE: Types. (line 6) 26937* TYPE_UNQUALIFIED: Types. (line 6) 26938* TYPE_VFIELD: Classes. (line 6) 26939* TYPENAME_TYPE: Types. (line 6) 26940* TYPENAME_TYPE_FULLNAME: Types. (line 6) 26941* TYPEOF_TYPE: Types. (line 6) 26942* udiv: Arithmetic. (line 110) 26943* udivM3 instruction pattern: Standard Names. (line 167) 26944* udivmodM4 instruction pattern: Standard Names. (line 214) 26945* UINTMAX_TYPE: Type Layout. (line 175) 26946* umax: Arithmetic. (line 123) 26947* umaxM3 instruction pattern: Standard Names. (line 167) 26948* umin: Arithmetic. (line 123) 26949* uminM3 instruction pattern: Standard Names. (line 167) 26950* umod: Arithmetic. (line 113) 26951* umodM3 instruction pattern: Standard Names. (line 167) 26952* umulhisi3 instruction pattern: Standard Names. (line 185) 26953* umulM3_highpart instruction pattern: Standard Names. (line 194) 26954* umulqihi3 instruction pattern: Standard Names. (line 185) 26955* umulsidi3 instruction pattern: Standard Names. (line 185) 26956* unchanging: Flags. (line 320) 26957* unchanging, in call_insn: Flags. (line 19) 26958* unchanging, in jump_insn, call_insn and insn: Flags. (line 24) 26959* unchanging, in reg and mem: Flags. (line 153) 26960* unchanging, in subreg: Flags. (line 195) 26961* unchanging, in symbol_ref: Flags. (line 10) 26962* UNION_TYPE <1>: Classes. (line 6) 26963* UNION_TYPE: Types. (line 6) 26964* unions, returning: Interface. (line 10) 26965* UNITS_PER_WORD: Storage Layout. (line 67) 26966* UNKNOWN_TYPE: Types. (line 6) 26967* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 29) 26968* unreachable code: Passes. (line 139) 26969* unshare_all_rtl: Sharing. (line 58) 26970* unsigned division: Arithmetic. (line 110) 26971* unsigned greater than: Comparisons. (line 61) 26972* unsigned less than: Comparisons. (line 65) 26973* unsigned minimum and maximum: Arithmetic. (line 123) 26974* unsigned_fix: Conversions. (line 73) 26975* unsigned_float: Conversions. (line 63) 26976* unspec: Side Effects. (line 280) 26977* unspec_volatile: Side Effects. (line 280) 26978* untyped_call instruction pattern: Standard Names. (line 648) 26979* untyped_return instruction pattern: Standard Names. (line 698) 26980* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 26981* US Software GOFAST, floating point emulation library: Library Calls. 26982 (line 34) 26983* us_minus: Arithmetic. (line 39) 26984* us_plus: Arithmetic. (line 33) 26985* US_SOFTWARE_GOFAST: Library Calls. (line 35) 26986* us_truncate: Conversions. (line 49) 26987* use: Side Effects. (line 155) 26988* USE_C_ALLOCA: Host Misc. (line 19) 26989* USE_LOAD_POST_DECREMENT: Costs. (line 143) 26990* USE_LOAD_POST_INCREMENT: Costs. (line 138) 26991* USE_LOAD_PRE_DECREMENT: Costs. (line 153) 26992* USE_LOAD_PRE_INCREMENT: Costs. (line 148) 26993* use_param: GTY Options. (line 107) 26994* use_paramN: GTY Options. (line 119) 26995* use_params: GTY Options. (line 127) 26996* USE_STORE_POST_DECREMENT: Costs. (line 163) 26997* USE_STORE_POST_INCREMENT: Costs. (line 158) 26998* USE_STORE_PRE_DECREMENT: Costs. (line 173) 26999* USE_STORE_PRE_INCREMENT: Costs. (line 168) 27000* used: Flags. (line 338) 27001* used, in symbol_ref: Flags. (line 222) 27002* USER_LABEL_PREFIX: Instruction Output. (line 126) 27003* USING_DECL: Declarations. (line 6) 27004* USING_STMT: Function Bodies. (line 6) 27005* V in constraint: Simple Constraints. (line 41) 27006* VA_ARG_EXPR: Expression trees. (line 6) 27007* values, returned by functions: Scalar Return. (line 6) 27008* VAR_DECL <1>: Expression trees. (line 6) 27009* VAR_DECL: Declarations. (line 6) 27010* varargs implementation: Varargs. (line 6) 27011* variable: Declarations. (line 6) 27012* VAX_FLOAT_FORMAT: Storage Layout. (line 391) 27013* vec_concat: Vector Operations. (line 25) 27014* vec_duplicate: Vector Operations. (line 30) 27015* vec_merge: Vector Operations. (line 11) 27016* vec_select: Vector Operations. (line 19) 27017* vector: Containers. (line 6) 27018* vector operations: Vector Operations. (line 6) 27019* VECTOR_CST: Expression trees. (line 6) 27020* VECTOR_MODE_SUPPORTED_P: Storage Layout. (line 357) 27021* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 27022* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 27023* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 27024* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 27025* VLIW <1>: Automaton pipeline description. 27026 (line 172) 27027* VLIW: Processor pipeline description. 27028 (line 6) 27029* VMS: Filesystem. (line 37) 27030* VMS_DEBUGGING_INFO: VMS Debug. (line 9) 27031* VOID_TYPE: Types. (line 6) 27032* VOIDmode: Machine Modes. (line 104) 27033* volatil: Flags. (line 352) 27034* volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags. 27035 (line 33) 27036* volatil, in label_ref and reg_label: Flags. (line 59) 27037* volatil, in mem, asm_operands, and asm_input: Flags. (line 88) 27038* volatil, in reg: Flags. (line 111) 27039* volatil, in subreg: Flags. (line 195) 27040* volatil, in symbol_ref: Flags. (line 231) 27041* volatile memory references: Flags. (line 353) 27042* voting between constraint alternatives: Class Preferences. (line 6) 27043* VTABLE_REF: Expression trees. (line 6) 27044* WCHAR_TYPE: Type Layout. (line 128) 27045* WCHAR_TYPE_SIZE: Type Layout. (line 136) 27046* web construction: Passes. (line 233) 27047* which_alternative: Output Statement. (line 59) 27048* WHILE_BODY: Function Bodies. (line 6) 27049* WHILE_COND: Function Bodies. (line 6) 27050* WHILE_STMT: Function Bodies. (line 6) 27051* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 83) 27052* WINT_TYPE: Type Layout. (line 156) 27053* word_mode: Machine Modes. (line 223) 27054* WORD_REGISTER_OPERATIONS: Misc. (line 88) 27055* WORD_SWITCH_TAKES_ARG: Driver. (line 20) 27056* WORDS_BIG_ENDIAN: Storage Layout. (line 29) 27057* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 132) 27058* X in constraint: Simple Constraints. (line 112) 27059* x-HOST: Host Fragment. (line 6) 27060* XCmode: Machine Modes. (line 111) 27061* XCOFF_DEBUGGING_INFO: DBX Options. (line 13) 27062* XEXP: Accessors. (line 6) 27063* XFmode: Machine Modes. (line 79) 27064* XINT: Accessors. (line 6) 27065* xm-MACHINE.h <1>: Host Misc. (line 6) 27066* xm-MACHINE.h: Filesystem. (line 6) 27067* xor: Arithmetic. (line 142) 27068* xor, canonicalization of: Insn Canonicalizations. 27069 (line 75) 27070* xorM3 instruction pattern: Standard Names. (line 167) 27071* XSTR: Accessors. (line 6) 27072* XVEC: Accessors. (line 41) 27073* XVECEXP: Accessors. (line 48) 27074* XVECLEN: Accessors. (line 44) 27075* XWINT: Accessors. (line 6) 27076* zero_extend: Conversions. (line 29) 27077* zero_extendMN2 instruction pattern: Standard Names. (line 502) 27078* zero_extract: Bit-Fields. (line 30) 27079* zero_extract, canonicalization of: Insn Canonicalizations. 27080 (line 87) 27081 27082 27083 27084Tag Table: 27085Node: Top2068 27086Node: Contributing4676 27087Node: Portability5419 27088Node: Interface7210 27089Node: Libgcc10629 27090Node: Integer library routines12384 27091Node: Soft float library routines19069 27092Node: Exception handling routines28533 27093Node: Miscellaneous routines29628 27094Node: Languages30011 27095Node: Source Tree31562 27096Node: Configure Terms32180 27097Node: Top Level35150 27098Node: gcc Directory37277 27099Node: Subdirectories38246 27100Node: Configuration40555 27101Node: Config Fragments41275 27102Node: System Config42619 27103Node: Configuration Files43563 27104Node: Build46251 27105Node: Makefile46663 27106Node: Library Files50845 27107Node: Headers51407 27108Node: Documentation53394 27109Node: Texinfo Manuals54195 27110Node: Man Page Generation56329 27111Node: Miscellaneous Docs58250 27112Node: Front End59607 27113Node: Front End Directory63376 27114Node: Front End Config68715 27115Node: Back End71462 27116Node: Testsuites74798 27117Node: Test Idioms75532 27118Node: Ada Tests79109 27119Node: C Tests80398 27120Node: libgcj Tests84755 27121Node: gcov Testing86187 27122Node: profopt Testing89184 27123Node: compat Testing90632 27124Node: Passes93983 27125Node: Trees117549 27126Node: Deficiencies120279 27127Node: Tree overview120516 27128Node: Macros and Functions124661 27129Node: Identifiers124807 27130Node: Containers126336 27131Node: Types127492 27132Node: Scopes140115 27133Node: Namespaces140879 27134Node: Classes143695 27135Node: Declarations148305 27136Node: Functions154368 27137Node: Function Basics156780 27138Node: Function Bodies163539 27139Node: Attributes177441 27140Node: Expression trees178684 27141Node: RTL204578 27142Node: RTL Objects206681 27143Node: RTL Classes210574 27144Node: Accessors215200 27145Node: Special Accessors217600 27146Node: Flags221468 27147Node: Machine Modes237787 27148Node: Constants246525 27149Node: Regs and Memory252493 27150Node: Arithmetic265546 27151Node: Comparisons273250 27152Node: Bit-Fields277385 27153Node: Vector Operations278813 27154Node: Conversions280437 27155Node: RTL Declarations283754 27156Node: Side Effects284573 27157Node: Incdec300442 27158Node: Assembler303786 27159Node: Insns305318 27160Node: Calls330557 27161Node: Sharing333161 27162Node: Reading RTL336271 27163Node: Machine Desc337264 27164Node: Overview339546 27165Node: Patterns341595 27166Node: Example345035 27167Node: RTL Template346476 27168Node: Output Template358951 27169Node: Output Statement362943 27170Node: Constraints366924 27171Node: Simple Constraints367865 27172Node: Multi-Alternative380254 27173Node: Class Preferences383103 27174Node: Modifiers383997 27175Node: Machine Constraints387771 27176Node: Standard Names409985 27177Ref: prologue instruction pattern454577 27178Ref: epilogue instruction pattern455070 27179Node: Pattern Ordering457521 27180Node: Dependent Patterns458757 27181Node: Jump Patterns461579 27182Node: Looping Patterns467338 27183Node: Insn Canonicalizations471953 27184Node: Expander Definitions475780 27185Node: Insn Splitting483924 27186Node: Including Patterns493547 27187Node: Peephole Definitions495343 27188Node: define_peephole496602 27189Node: define_peephole2502964 27190Node: Insn Attributes506041 27191Node: Defining Attributes507147 27192Node: Expressions509176 27193Node: Tagging Insns515780 27194Node: Attr Example520148 27195Node: Insn Lengths522530 27196Node: Constant Attributes525603 27197Node: Delay Slots526774 27198Node: Processor pipeline description530012 27199Node: Old pipeline description533968 27200Node: Automaton pipeline description539703 27201Node: Comparison of the two descriptions554614 27202Node: Conditional Execution556612 27203Node: Constant Definitions559475 27204Node: Target Macros561060 27205Node: Target Structure563893 27206Node: Driver565162 27207Node: Run-time Target585968 27208Node: Per-Function Data596558 27209Node: Storage Layout599328 27210Node: Type Layout623682 27211Node: Escape Sequences634728 27212Node: Registers635605 27213Node: Register Basics636535 27214Node: Allocation Order642420 27215Node: Values in Registers643865 27216Node: Leaf Functions649188 27217Node: Stack Registers652006 27218Node: Register Classes653124 27219Node: Stack and Calling678500 27220Node: Frame Layout679005 27221Node: Exception Handling686614 27222Node: Stack Checking692532 27223Node: Frame Registers696165 27224Node: Elimination702771 27225Node: Stack Arguments706802 27226Node: Register Arguments714771 27227Node: Scalar Return727448 27228Node: Aggregate Return732221 27229Node: Caller Saves735561 27230Node: Function Entry736739 27231Node: Profiling749374 27232Node: Tail Calls751032 27233Node: Varargs751866 27234Node: Trampolines759806 27235Node: Library Calls766594 27236Node: Addressing Modes770710 27237Node: Condition Code781714 27238Node: Costs789849 27239Node: Scheduling801601 27240Node: Sections817452 27241Node: PIC827973 27242Node: Assembler Format830819 27243Node: File Framework831898 27244Node: Data Output837970 27245Node: Uninitialized Data845403 27246Node: Label Output850935 27247Node: Initialization870036 27248Node: Macros for Initialization876030 27249Node: Instruction Output882323 27250Node: Dispatch Tables891319 27251Node: Exception Region Output893955 27252Node: Alignment Output898453 27253Node: Debugging Info902597 27254Node: All Debuggers903267 27255Node: DBX Options906122 27256Node: DBX Hooks911436 27257Node: File Names and DBX915051 27258Node: SDB and DWARF916375 27259Node: VMS Debug920093 27260Node: Floating Point920663 27261Node: Mode Switching925490 27262Node: Target Attributes929415 27263Node: MIPS Coprocessors933310 27264Node: PCH Target934892 27265Node: Misc936150 27266Node: Host Config970517 27267Node: Host Common971579 27268Node: Filesystem973755 27269Node: Host Misc977310 27270Node: Fragments979507 27271Node: Target Fragment980706 27272Node: Host Fragment986134 27273Node: Collect2987578 27274Node: Header Dirs990135 27275Node: Type Information991565 27276Node: GTY Options992623 27277Node: GGC Roots1001076 27278Node: Files1001785 27279Node: Funding1004637 27280Node: GNU Project1007145 27281Node: Copying1007796 27282Node: GNU Free Documentation License1026975 27283Node: Contributors1049380 27284Node: Option Index1076913 27285Node: Index1079096 27286 27287End Tag Table 27288