![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-5 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-5 CVS log | Up to [GCC 1.x] / gcc |
1.1.1.7 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.47 from the input 1.1 root 2: file gcc.texinfo. 3: 1.1.1.6 root 4: This file documents the use and the internals of the GNU compiler. 1.1 root 5: 1.1.1.6 root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc. 1.1 root 7: 1.1.1.7 ! root 8: Permission is granted to make and distribute verbatim copies of this ! 9: manual provided the copyright notice and this permission notice are ! 10: preserved on all copies. 1.1 root 11: 1.1.1.6 root 12: Permission is granted to copy and distribute modified versions of 1.1 root 13: this manual under the conditions for verbatim copying, provided also 1.1.1.4 root 14: that the sections entitled "GNU General Public License" and "Protect 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the 16: original, and provided that the entire resulting derived work is 17: distributed under the terms of a permission notice identical to this 18: one. 1.1 root 19: 1.1.1.6 root 20: Permission is granted to copy and distribute translations of this 1.1 root 21: manual into another language, under the above conditions for modified 1.1.1.4 root 22: versions, except that the sections entitled "GNU General Public 23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this 1.1.1.7 ! root 24: permission notice may be included in translations approved by the Free ! 25: Software Foundation instead of in the original English. 1.1 root 26: 1.1.1.6 root 27: 28: File: gcc.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Bugs 29: 30: How to Report Bugs 31: ================== 32: 33: Send bug reports for GNU C to one of these addresses: 34: 35: [email protected] 36: {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gcc 37: 38: *Do not send bug reports to `help-gcc', or to the newsgroup 39: `gnu.gcc.help'.* Most users of GNU CC do not want to receive bug 40: reports. Those that do, have asked to be on `bug-gcc'. 41: 42: The mailing list `bug-gcc' has a newsgroup which serves as a 43: repeater. The mailing list and the newsgroup carry exactly the same 44: messages. Often people think of posting bug reports to the newsgroup 1.1.1.7 ! root 45: instead of mailing them. This appears to work, but it has one problem ! 46: which can be crucial: a newsgroup posting does not contain a mail path ! 47: back to the sender. Thus, if I need to ask for more information, I may ! 48: be unable to reach you. For this reason, it is better to send bug ! 49: reports to the mailing list. 1.1.1.6 root 50: 51: As a last resort, send bug reports on paper to: 52: 53: GNU Compiler Bugs 54: Free Software Foundation 55: 675 Mass Ave 56: Cambridge, MA 02139 57: 58: The fundamental principle of reporting bugs usefully is this: 1.1.1.7 ! root 59: *report all the facts*. If you are not sure whether to state a fact or ! 60: leave it out, state it! 1.1.1.6 root 61: 1.1.1.7 ! root 62: Often people omit facts because they think they know what causes the ! 63: problem and they conclude that some details don't matter. Thus, you ! 64: might assume that the name of the variable you use in an example does ! 65: not matter. Well, probably it doesn't, but one cannot be sure. Perhaps ! 66: the bug is a stray memory reference which happens to fetch from the ! 67: location where that name is stored in memory; perhaps, if the name were ! 68: different, the contents of that location would fool the compiler into ! 69: doing the right thing despite the bug. Play it safe and give a ! 70: specific, complete example. That is the easiest thing for you to do, ! 71: and the most helpful. ! 72: ! 73: Keep in mind that the purpose of a bug report is to enable me to fix ! 74: the bug if it is not known. It isn't very important what happens if ! 75: the bug is already known. Therefore, always write your bug reports on ! 76: the assumption that the bug is not known. ! 77: ! 78: Sometimes people give a few sketchy facts and ask, "Does this ring a ! 79: bell?" Those bug reports are useless, and I urge everyone to *refuse ! 80: to respond to them* except to chide the sender to report bugs properly. 1.1.1.6 root 81: 82: To enable me to fix the bug, you should include all these things: 83: 84: * The version of GNU CC. You can get this by running it with the 85: `-v' option. 86: 87: Without this, I won't know whether there is any point in looking 88: for the bug in the current version of GNU CC. 89: 1.1.1.7 ! root 90: * A complete input file that will reproduce the bug. If the bug is ! 91: in the C preprocessor, send me a source file and any header files ! 92: that it requires. If the bug is in the compiler proper (`cc1'), ! 93: run your source file through the C preprocessor by doing `gcc -E ! 94: SOURCEFILE > OUTFILE', then include the contents of OUTFILE in the ! 95: bug report. (Any `-I', `-D' or `-U' options that you used in ! 96: actual compilation should also be used when doing this.) 1.1.1.6 root 97: 98: A single statement is not enough of an example. In order to 1.1.1.7 ! root 99: compile it, it must be embedded in a function definition; and the ! 100: bug might depend on the details of how this is done. 1.1.1.6 root 101: 1.1.1.7 ! root 102: Without a real example I can compile, all I can do about your bug ! 103: report is wish you luck. It would be futile to try to guess how to ! 104: provoke the bug. For example, bugs in register allocation and ! 105: reloading frequently depend on every little detail of the function ! 106: they happen in. ! 107: ! 108: * The command arguments you gave GNU CC to compile that example and ! 109: observe the bug. For example, did you use `-O'? To guarantee you ! 110: won't omit something important, list them all. 1.1.1.6 root 111: 112: If I were to try to guess the arguments, I would probably guess 113: wrong and then I would not encounter the bug. 114: 1.1.1.7 ! root 115: * The names of the files that you used for `tm.h' and `md' when you ! 116: installed the compiler. 1.1.1.6 root 117: 118: * The type of machine you are using, and the operating system name 119: and version number. 120: 121: * A description of what behavior you observe that you believe is 1.1.1.7 ! root 122: incorrect. For example, "It gets a fatal signal," or, "There is an ! 123: incorrect assembler instruction in the output." 1.1.1.6 root 124: 125: Of course, if the bug is that the compiler gets a fatal signal, 126: then I will certainly notice it. But if the bug is incorrect 1.1.1.7 ! root 127: output, I might not notice unless it is glaringly wrong. I won't ! 128: study all the assembler code from a 50-line C program just on the ! 129: off chance that it might be wrong. 1.1.1.6 root 130: 131: Even if the problem you experience is a fatal signal, you should 132: still say so explicitly. Suppose something strange is going on, 133: such as, your copy of the compiler is out of synch, or you have 134: encountered a bug in the C library on your system. (This has 1.1.1.7 ! root 135: happened!) Your copy might crash and mine would not. If you told ! 136: me to expect a crash, then when mine fails to crash, I would know ! 137: that the bug was not happening for me. If you had not told me to ! 138: expect a crash, then I would not be able to draw any conclusion ! 139: from my observations. 1.1.1.6 root 140: 141: Often the observed symptom is incorrect output when your program 1.1.1.7 ! root 142: is run. Sad to say, this is not enough information for me unless ! 143: the program is short and simple. If you send me a large program, ! 144: I don't have time to figure out how it would work if compiled ! 145: correctly, much less which line of it was compiled wrong. So you ! 146: will have to do that. Tell me which source line it is, and what ! 147: incorrect result happens when that line is executed. A person who ! 148: understands the test program can find this as easily as a bug in ! 149: the program itself. 1.1.1.6 root 150: 151: * If you send me examples of output from GNU CC, please use `-g' 1.1.1.7 ! root 152: when you make them. The debugging information includes source line ! 153: numbers which are essential for correlating the output with the ! 154: input. 1.1.1.6 root 155: 156: * If you wish to suggest changes to the GNU CC source, send me 157: context diffs. If you even discuss something in the GNU CC 158: source, refer to it by context, not by line number. 159: 160: The line numbers in my development sources don't match those in 161: your sources. Your line numbers would convey no useful 162: information to me. 163: 164: * Additional information from a debugger might enable me to find a 1.1.1.7 ! root 165: problem on a machine which I do not have available myself. 1.1.1.6 root 166: However, you need to think when you collect this information if 167: you want it to have any chance of being useful. 168: 1.1.1.7 ! root 169: For example, many people send just a backtrace, but that is never ! 170: useful by itself. A simple backtrace with arguments conveys little ! 171: about GNU CC because the compiler is largely data-driven; the same ! 172: functions are called over and over for different RTL insns, doing ! 173: different things depending on the details of the insn. ! 174: ! 175: Most of the arguments listed in the backtrace are useless because ! 176: they are pointers to RTL list structure. The numeric values of the ! 177: pointers, which the debugger prints in the backtrace, have no ! 178: significance whatever; all that matters is the contents of the ! 179: objects they point to (and most of the contents are other such ! 180: pointers). ! 181: ! 182: In addition, most compiler passes consist of one or more loops that ! 183: scan the RTL insn sequence. The most vital piece of information ! 184: about such a loop--which insn it has reached--is usually in a ! 185: local variable, not in an argument. ! 186: ! 187: What you need to provide in addition to a backtrace are the values ! 188: of the local variables for several stack frames up. When a local ! 189: variable or an argument is an RTX, first print its value and then ! 190: use the GDB command `pr' to print the RTL expression that it points ! 191: to. (If GDB doesn't run on your machine, use your debugger to call ! 192: the function `debug_rtx' with the RTX as an argument.) In ! 193: general, whenever a variable is a pointer, its value is no use ! 194: without the data it points to. ! 195: ! 196: In addition, include a debugging dump from just before the pass in ! 197: which the crash happens. Most bugs involve a series of insns, not ! 198: just one. 1.1.1.6 root 199: 200: Here are some things that are not necessary: 201: 202: * A description of the envelope of the bug. 203: 1.1.1.7 ! root 204: Often people who encounter a bug spend a lot of time investigating ! 205: which changes to the input file will make the bug go away and which ! 206: changes will not affect it. ! 207: ! 208: This is often time consuming and not very useful, because the way I ! 209: will find the bug is by running a single example under the debugger ! 210: with breakpoints, not by pure deduction from a series of examples. ! 211: I recommend that you save your time for something else. 1.1.1.6 root 212: 213: Of course, if you can find a simpler example to report *instead* 1.1.1.7 ! root 214: of the original one, that is a convenience for me. Errors in the ! 215: output will be easier to spot, running under the debugger will take ! 216: less time, etc. Most GNU CC bugs involve just one function, so the ! 217: most straightforward way to simplify an example is to delete all ! 218: the function definitions except the one where the bug occurs. ! 219: Those earlier in the file may be replaced by external declarations ! 220: if the crucial function depends on them. (Exception: inline ! 221: functions may affect compilation of functions defined later in the ! 222: file.) ! 223: ! 224: However, simplification is not vital; if you don't want to do this, ! 225: report the bug anyway and send me the entire test case you used. 1.1.1.6 root 226: 227: * A patch for the bug. 228: 229: A patch for the bug does help me if it is a good one. But don't 230: omit the necessary information, such as the test case, on the 1.1.1.7 ! root 231: assumption that a patch is all I need. I might see problems with ! 232: your patch and decide to fix the problem another way, or I might ! 233: not understand it at all. ! 234: ! 235: Sometimes with a program as complicated as GNU CC it is very hard ! 236: to construct an example that will make the program follow a ! 237: certain path through the code. If you don't send me the example, ! 238: I won't be able to construct one, so I won't be able to verify ! 239: that the bug is fixed. 1.1.1.6 root 240: 241: And if I can't understand what bug you are trying to fix, or why 242: your patch should be an improvement, I won't install it. A test 243: case will help me to understand. 244: 245: * A guess about what the bug is or what it depends on. 246: 247: Such guesses are usually wrong. Even I can't guess right about 248: such things without first using the debugger to find the facts. 249: 250: 251: File: gcc.info, Node: Portability, Next: Interface, Prev: Bugs, Up: Top 252: 253: GNU CC and Portability 254: ********************** 255: 256: The main goal of GNU CC was to make a good, fast compiler for 257: machines in the class that the GNU system aims to run on: 32-bit 1.1.1.7 ! root 258: machines that address 8-bit bytes and have several general registers. 1.1.1.6 root 259: Elegance, theoretical power and simplicity are only secondary. 260: 1.1.1.7 ! root 261: GNU CC gets most of the information about the target machine from a ! 262: machine description which gives an algebraic formula for each of the ! 263: machine's instructions. This is a very clean way to describe the 1.1.1.6 root 264: target. But when the compiler needs information that is difficult to 265: express in this fashion, I have not hesitated to define an ad-hoc 1.1.1.7 ! root 266: parameter to the machine description. The purpose of portability is to ! 267: reduce the total work needed on the compiler; it was not of interest ! 268: for its own sake. ! 269: ! 270: GNU CC does not contain machine dependent code, but it does contain ! 271: code that depends on machine parameters such as endianness (whether the ! 272: most significant byte has the highest or lowest address of the bytes in ! 273: a word) and the availability of autoincrement addressing. In the ! 274: RTL-generation pass, it is often necessary to have multiple strategies ! 275: for generating code for a particular kind of syntax tree, strategies ! 276: that are usable for different combinations of parameters. Often I have ! 277: not tried to address all possible cases, but only the common ones or ! 278: only the ones that I have encountered. As a result, a new target may ! 279: require additional strategies. You will know if this happens because ! 280: the compiler will call `abort'. Fortunately, the new strategies can be ! 281: added in a machine-independent fashion, and will affect only the target ! 282: machines that need them. 1.1.1.2 root 283: 284: 1.1.1.5 root 285: File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top 286: 287: Interfacing to GNU CC Output 288: **************************** 289: 1.1.1.6 root 290: GNU CC is normally configured to use the same function calling 1.1.1.7 ! root 291: convention normally in use on the target system. This is done with the ! 292: machine-description macros described (*note Machine Macros::.). 1.1.1.5 root 293: 1.1.1.7 ! root 294: However, returning of structure and union values is done differently ! 295: on some target machines. As a result, functions compiled with PCC ! 296: returning such types cannot be called from code compiled with GNU CC, ! 297: and vice versa. This does not cause trouble often because few Unix ! 298: library routines return structures or unions. ! 299: ! 300: GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes ! 301: long in the same registers used for `int' or `double' return values. ! 302: (GNU CC typically allocates variables of such types in registers also.) ! 303: Structures and unions of other sizes are returned by storing them into ! 304: an address passed by the caller (usually in a register). The ! 305: machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE' ! 306: tell GNU CC where to pass this address. 1.1.1.5 root 307: 1.1.1.6 root 308: By contrast, PCC on most target machines returns structures and 1.1.1.7 ! root 309: unions of any size by copying the data into an area of static storage, ! 310: and then returning the address of that storage as if it were a pointer ! 311: value. The caller must copy the data from that memory area to the place ! 312: where the value is wanted. This is slower than the method used by GNU ! 313: CC, and fails to be reentrant. 1.1.1.5 root 314: 1.1.1.6 root 315: On some target machines, such as RISC machines and the 80386, the 1.1.1.7 ! root 316: standard system convention is to pass to the subroutine the address of ! 317: where to return the value. On these machines, GNU CC has been ! 318: configured to be compatible with the standard compiler, when this method ! 319: is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes. ! 320: ! 321: GNU CC uses the system's standard convention for passing arguments. ! 322: On some machines, the first few arguments are passed in registers; in ! 323: others, all are passed on the stack. It would be possible to use ! 324: registers for argument passing on any machine, and this would probably ! 325: result in a significant speedup. But the result would be complete ! 326: incompatibility with code that follows the standard convention. So this ! 327: change is practical only if you are switching to GNU CC as the sole C ! 328: compiler for the system. We may implement register argument passing on ! 329: certain machines once we have a complete GNU system so that we can ! 330: compile the libraries with GNU CC. 1.1.1.5 root 331: 1.1.1.6 root 332: If you use `longjmp', beware of automatic variables. ANSI C says 1.1.1.7 ! root 333: that automatic variables that are not declared `volatile' have undefined ! 334: values after a `longjmp'. And this is all GNU CC promises to do, ! 335: because it is very difficult to restore register variables correctly, ! 336: and one of GNU CC's features is that it can put variables in registers ! 337: without your asking it to. 1.1.1.5 root 338: 1.1.1.6 root 339: If you want a variable to be unaltered by `longjmp', and you don't 1.1.1.7 ! root 340: want to write `volatile' because old C compilers don't accept it, just ! 341: take the address of the variable. If a variable's address is ever ! 342: taken, even if just to compute it and ignore it, then the variable ! 343: cannot go in a register: 1.1.1.5 root 344: 345: { 346: int careful; 347: &careful; 348: ... 349: } 350: 1.1.1.7 ! root 351: Code compiled with GNU CC may call certain library routines. Most of ! 352: them handle arithmetic for which there are no instructions. This 1.1.1.5 root 353: includes multiply and divide on some machines, and floating point 1.1.1.7 ! root 354: operations on any machine for which floating point support is disabled ! 355: with `-msoft-float'. Some standard parts of the C library, such as ! 356: `bcopy' or `memcpy', are also called automatically. The usual function ! 357: call interface is used for calling the library routines. 1.1.1.5 root 358: 1.1.1.6 root 359: These library routines should be defined in the library `gnulib', 1.1.1.5 root 360: which GNU CC automatically searches whenever it links a program. On 361: machines that have multiply and divide instructions, if hardware 362: floating point is in use, normally `gnulib' is not needed, but it is 363: searched just in case. 364: 1.1.1.6 root 365: Each arithmetic function is defined in `gnulib.c' to use the 1.1.1.5 root 366: corresponding C arithmetic operator. As long as the file is compiled 1.1.1.7 ! root 367: with another C compiler, which supports all the C arithmetic operators, ! 368: this file will work portably. However, `gnulib.c' does not work if ! 369: compiled with GNU CC, because each arithmetic function would compile ! 370: into a call to itself! 1.1.1.5 root 371: 372: 1.1.1.3 root 373: File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top 1.1.1.2 root 374: 1.1.1.3 root 375: Passes and Files of the Compiler 376: ******************************** 1.1.1.2 root 377: 1.1.1.7 ! root 378: The overall control structure of the compiler is in `toplev.c'. This ! 379: file is responsible for initialization, decoding arguments, opening and ! 380: closing files, and sequencing the passes. 1.1.1.3 root 381: 1.1.1.6 root 382: The parsing pass is invoked only once, to parse the entire input. 1.1.1.3 root 383: The RTL intermediate code for a function is generated as the function 384: is parsed, a statement at a time. Each statement is read in as a 385: syntax tree and then converted to RTL; then the storage for the tree 1.1.1.7 ! root 386: for the statement is reclaimed. Storage for types (and the expressions ! 387: for their sizes), declarations, and a representation of the binding ! 388: contours and how they nest, remains until the function is finished ! 389: being compiled; these are all needed to output the debugging 1.1.1.3 root 390: information. 391: 1.1.1.6 root 392: Each time the parsing pass reads a complete function definition or 1.1.1.3 root 393: top-level declaration, it calls the function `rest_of_compilation' or 1.1.1.7 ! root 394: `rest_of_decl_compilation' in `toplev.c', which are responsible for all ! 395: further processing necessary, ending with output of the assembler 1.1.1.3 root 396: language. All other compiler passes run, in sequence, within 1.1.1.7 ! root 397: `rest_of_compilation'. When that function returns from compiling a 1.1.1.3 root 398: function definition, the storage used for that function definition's 399: compilation is entirely freed, unless it is an inline function (*note 400: Inline::.). 401: 1.1.1.6 root 402: Here is a list of all the passes of the compiler and their source 1.1.1.7 ! root 403: files. Also included is a description of where debugging dumps can be ! 404: requested with `-d' options. 1.1.1.3 root 405: 1.1.1.7 ! root 406: * Parsing. This pass reads the entire text of a function definition, ! 407: constructing partial syntax trees. This and RTL generation are no ! 408: longer truly separate passes (formerly they were), but it is ! 409: easier to think of them as separate. ! 410: ! 411: The tree representation does not entirely follow C syntax, because ! 412: it is intended to support other languages as well. ! 413: ! 414: C data type analysis is also done in this pass, and every tree node ! 415: that represents an expression has a data type attached. Variables ! 416: are represented as declaration nodes. 1.1.1.3 root 417: 1.1.1.7 ! root 418: Constant folding and associative-law simplifications are also done ! 419: during this pass. 1.1.1.3 root 420: 421: The source files for parsing are `c-parse.y', `c-decl.c', 1.1.1.7 ! root 422: `c-typeck.c', `c-convert.c', `stor-layout.c', `fold-const.c', and ! 423: `tree.c'. The last three files are intended to be 1.1.1.3 root 424: language-independent. There are also header files `c-parse.h', 1.1.1.7 ! root 425: `c-tree.h', `tree.h' and `tree.def'. The last two define the 1.1.1.3 root 426: format of the tree representation. 427: 428: * RTL generation. This is the conversion of syntax tree into RTL 1.1.1.7 ! root 429: code. It is actually done statement-by-statement during parsing, ! 430: but for most purposes it can be thought of as a separate pass. ! 431: ! 432: This is where the bulk of target-parameter-dependent code is found, ! 433: since often it is necessary for strategies to apply only when ! 434: certain standard kinds of instructions are available. The purpose ! 435: of named instruction patterns is to provide this information to ! 436: the RTL generation pass. 1.1.1.3 root 437: 438: Optimization is done in this pass for `if'-conditions that are 1.1.1.7 ! root 439: comparisons, boolean operations or conditional expressions. Tail ! 440: recursion is detected at this time also. Decisions are made about ! 441: how best to arrange loops and how to output `switch' statements. 1.1.1.3 root 442: 443: The source files for RTL generation are `stmt.c', `expr.c', 1.1.1.7 ! root 444: `explow.c', `expmed.c', `optabs.c' and `emit-rtl.c'. Also, the ! 445: file `insn-emit.c', generated from the machine description by the ! 446: program `genemit', is used in this pass. The header files 1.1.1.3 root 447: `expr.h' is used for communication within this pass. 448: 1.1.1.7 ! root 449: The header files `insn-flags.h' and `insn-codes.h', generated from ! 450: the machine description by the programs `genflags' and `gencodes', ! 451: tell this pass which standard names are available for use and ! 452: which patterns correspond to them. 1.1.1.3 root 453: 454: Aside from debugging information output, none of the following 1.1.1.7 ! root 455: passes refers to the tree structure representation of the function ! 456: (only part of which is saved). 1.1.1.3 root 457: 458: The decision of whether the function can and should be expanded 459: inline in its subsequent callers is made at the end of rtl 460: generation. The function must meet certain criteria, currently 461: related to the size of the function and the types and number of 462: parameters it has. Note that this function may contain loops, 463: recursive calls to itself (tail-recursive functions can be 464: inlined!), gotos, in short, all constructs supported by GNU CC. 465: 466: The option `-dr' causes a debugging dump of the RTL code after 467: this pass. This dump file's name is made by appending `.rtl' to 468: the input file name. 469: 470: * Jump optimization. This pass simplifies jumps to the following 471: instruction, jumps across jumps, and jumps to jumps. It deletes 1.1.1.7 ! root 472: unreferenced labels and unreachable code, except that unreachable ! 473: code that contains a loop is not recognized as unreachable in this ! 474: pass. (Such loops are deleted later in the basic block analysis.) ! 475: ! 476: Jump optimization is performed two or three times. The first time ! 477: is immediately following RTL generation. The second time is after ! 478: CSE, but only if CSE says repeated jump optimization is needed. ! 479: The last time is right before the final pass. That time, ! 480: cross-jumping and deletion of no-op move instructions are done ! 481: together with the optimizations described above. 1.1.1.3 root 482: 483: The source file of this pass is `jump.c'. 484: 485: The option `-dj' causes a debugging dump of the RTL code after 486: this pass is run for the first time. This dump file's name is 487: made by appending `.jump' to the input file name. 488: 489: * Register scan. This pass finds the first and last use of each 490: register, as a guide for common subexpression elimination. Its 491: source is in `regclass.c'. 492: 493: * Common subexpression elimination. This pass also does constant 1.1.1.7 ! root 494: propagation. Its source file is `cse.c'. If constant propagation ! 495: causes conditional jumps to become unconditional or to become ! 496: no-ops, jump optimization is run again when CSE is finished. 1.1.1.3 root 497: 498: The option `-ds' causes a debugging dump of the RTL code after 499: this pass. This dump file's name is made by appending `.cse' to 500: the input file name. 501: 502: * Loop optimization. This pass moves constant expressions out of 1.1.1.7 ! root 503: loops, and optionally does strength-reduction as well. Its source ! 504: file is `loop.c'. 1.1.1.3 root 505: 506: The option `-dL' causes a debugging dump of the RTL code after 1.1.1.7 ! root 507: this pass. This dump file's name is made by appending `.loop' to ! 508: the input file name. 1.1.1.3 root 509: 510: * Stupid register allocation is performed at this point in a 1.1.1.7 ! root 511: nonoptimizing compilation. It does a little data flow analysis as ! 512: well. When stupid register allocation is in use, the next pass ! 513: executed is the reloading pass; the others in between are skipped. ! 514: The source file is `stupid.c'. ! 515: ! 516: * Data flow analysis (`flow.c'). This pass divides the program into ! 517: basic blocks (and in the process deletes unreachable loops); then ! 518: it computes which pseudo-registers are live at each point in the ! 519: program, and makes the first instruction that uses a value point at ! 520: the instruction that computed the value. ! 521: ! 522: This pass also deletes computations whose results are never used, ! 523: and combines memory references with add or subtract instructions ! 524: to make autoincrement or autodecrement addressing. 1.1.1.3 root 525: 526: The option `-df' causes a debugging dump of the RTL code after 1.1.1.7 ! root 527: this pass. This dump file's name is made by appending `.flow' to ! 528: the input file name. If stupid register allocation is in use, this ! 529: dump file reflects the full results of such allocation. 1.1.1.3 root 530: 531: * Instruction combination (`combine.c'). This pass attempts to 532: combine groups of two or three instructions that are related by 533: data flow into single instructions. It combines the RTL 534: expressions for the instructions by substitution, simplifies the 535: result using algebra, and then attempts to match the result 536: against the machine description. 537: 538: The option `-dc' causes a debugging dump of the RTL code after 1.1.1.7 ! root 539: this pass. This dump file's name is made by appending `.combine' ! 540: to the input file name. 1.1.1.3 root 541: 1.1.1.7 ! root 542: * Register class preferencing. The RTL code is scanned to find out ! 543: which register class is best for each pseudo register. The source ! 544: file is `regclass.c'. ! 545: ! 546: * Local register allocation (`local-alloc.c'). This pass allocates ! 547: hard registers to pseudo registers that are used only within one ! 548: basic block. Because the basic block is linear, it can use fast ! 549: and powerful techniques to do a very good job. 1.1.1.3 root 550: 551: The option `-dl' causes a debugging dump of the RTL code after 1.1.1.7 ! root 552: this pass. This dump file's name is made by appending `.lreg' to ! 553: the input file name. 1.1.1.3 root 554: 555: * Global register allocation (`global-alloc.c'). This pass 1.1.1.7 ! root 556: allocates hard registers for the remaining pseudo registers (those ! 557: whose life spans are not contained in one basic block). 1.1.1.3 root 558: 1.1.1.7 ! root 559: * Reloading. This pass renumbers pseudo registers with the hardware ! 560: registers numbers they were allocated. Pseudo registers that did ! 561: not get hard registers are replaced with stack slots. Then it ! 562: finds instructions that are invalid because a value has failed to ! 563: end up in a register, or has ended up in a register of the wrong ! 564: kind. It fixes up these instructions by reloading the ! 565: problematical values temporarily into registers. Additional ! 566: instructions are generated to do the copying. 1.1.1.3 root 567: 568: Source files are `reload.c' and `reload1.c', plus the header 569: `reload.h' used for communication between them. 570: 571: The option `-dg' causes a debugging dump of the RTL code after 1.1.1.7 ! root 572: this pass. This dump file's name is made by appending `.greg' to ! 573: the input file name. 1.1.1.3 root 574: 575: * Jump optimization is repeated, this time including cross-jumping 576: and deletion of no-op move instructions. 577: 578: The option `-dJ' causes a debugging dump of the RTL code after 1.1.1.7 ! root 579: this pass. This dump file's name is made by appending `.jump2' to ! 580: the input file name. 1.1.1.3 root 581: 582: * Delayed branch scheduling may be done at this point. The source 583: file name is `dbranch.c'. 584: 585: The option `-dd' causes a debugging dump of the RTL code after 586: this pass. This dump file's name is made by appending `.dbr' to 587: the input file name. 588: 1.1.1.7 ! root 589: * Final. This pass outputs the assembler code for the function. It ! 590: is also responsible for identifying spurious test and compare 1.1.1.3 root 591: instructions. Machine-specific peephole optimizations are 1.1.1.7 ! root 592: performed at the same time. The function entry and exit sequences ! 593: are generated directly as assembler code in this pass; they never ! 594: exist as RTL. ! 595: ! 596: The source files are `final.c' plus `insn-output.c'; the latter is ! 597: generated automatically from the machine description by the tool ! 598: `genoutput'. The header file `conditions.h' is used for 1.1.1.3 root 599: communication between these files. 600: 1.1.1.7 ! root 601: * Debugging information output. This is run after final because it ! 602: must output the stack slot offsets for pseudo registers that did ! 603: not get hard registers. Source files are `dbxout.c' for DBX 1.1.1.3 root 604: symbol table format and `symout.c' for GDB's own symbol table 605: format. 606: 1.1.1.6 root 607: Some additional files are used by all or many passes: 1.1.1.3 root 608: 609: * Every pass uses `machmode.def', which defines the machine modes. 610: 1.1.1.7 ! root 611: * All the passes that work with RTL use the header files `rtl.h' and ! 612: `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also ! 613: use these files to read and work with the machine description RTL. 1.1.1.3 root 614: 615: * Several passes refer to the header file `insn-config.h' which 616: contains a few parameters (C macro definitions) generated 617: automatically from the machine description RTL by the tool 618: `genconfig'. 619: 620: * Several passes use the instruction recognizer, which consists of 621: `recog.c' and `recog.h', plus the files `insn-recog.c' and 1.1.1.7 ! root 622: `insn-extract.c' that are generated automatically from the machine ! 623: description by the tools `genrecog' and `genextract'. 1.1.1.3 root 624: 625: * Several passes use the header files `regs.h' which defines the 626: information recorded about pseudo register usage, and 1.1.1.7 ! root 627: `basic-block.h' which defines the information recorded about basic ! 628: blocks. 1.1.1.3 root 629: 630: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector 631: with a bit for each hard register, and some macros to manipulate 1.1.1.7 ! root 632: it. This type is just `int' if the machine has few enough hard 1.1.1.3 root 633: registers; otherwise it is an array of `int' and some of the 634: macros expand into loops. 1.1.1.2 root 635: 636: 1.1.1.3 root 637: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top 1.1.1.2 root 638: 1.1.1.3 root 639: RTL Representation 640: ****************** 1.1.1.2 root 641: 1.1.1.6 root 642: Most of the work of the compiler is done on an intermediate 1.1.1.3 root 643: representation called register transfer language. In this language, 1.1.1.7 ! root 644: the instructions to be output are described, pretty much one by one, in ! 645: an algebraic form that describes what the instruction does. 1.1.1.3 root 646: 1.1.1.6 root 647: RTL is inspired by Lisp lists. It has both an internal form, made 648: up of structures that point at other structures, and a textual form 1.1.1.7 ! root 649: that is used in the machine description and in printed debugging dumps. ! 650: The textual form uses nested parentheses to indicate the pointers in ! 651: the internal form. 1.1.1.2 root 652: 1.1.1.3 root 653: * Menu: 1.1.1.2 root 654: 1.1.1.3 root 655: * RTL Objects:: Expressions vs vectors vs strings vs integers. 656: * Accessors:: Macros to access expression operands or vector elts. 657: * Flags:: Other flags in an RTL expression. 658: * Machine Modes:: Describing the size and format of a datum. 659: * Constants:: Expressions with constant values. 660: * Regs and Memory:: Expressions representing register contents or memory. 661: * Arithmetic:: Expressions representing arithmetic on other expressions. 662: * Comparisons:: Expressions representing comparison of expressions. 663: * Bit Fields:: Expressions representing bit-fields in memory or reg. 664: * Conversions:: Extending, truncating, floating or fixing. 665: * RTL Declarations:: Declaring volatility, constancy, etc. 666: * Side Effects:: Expressions for storing in registers, etc. 667: * Incdec:: Embedded side-effects for autoincrement addressing. 668: * Assembler:: Representing `asm' with operands. 669: * Insns:: Expression types for entire insns. 670: * Calls:: RTL representation of function call insns. 671: * Sharing:: Some expressions are unique; others *must* be copied. 1.1.1.2 root 672: 1.1.1.3 root 673: 674: File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL 1.1.1.2 root 675: 1.1.1.3 root 676: RTL Object Types 677: ================ 1.1.1.2 root 678: 1.1.1.6 root 679: RTL uses four kinds of objects: expressions, integers, strings and 1.1.1.7 ! root 680: vectors. Expressions are the most important ones. An RTL expression ! 681: ("RTX", for short) is a C structure, but it is usually referred to with ! 682: a pointer; a type that is given the typedef name `rtx'. ! 683: ! 684: An integer is simply an `int', and a string is a `char *'. Within ! 685: RTL code, strings appear only inside `symbol_ref' expressions, but they ! 686: appear in other contexts in the RTL expressions that make up machine ! 687: descriptions. Their written form uses decimal digits. ! 688: ! 689: A string is a sequence of characters. In core it is represented as a ! 690: `char *' in usual C fashion, and it is written in C syntax as well. ! 691: However, strings in RTL may never be null. If you write an empty ! 692: string in a machine description, it is represented in core as a null ! 693: pointer rather than as a pointer to a null character. In certain ! 694: contexts, these null pointers instead of strings are valid. 1.1.1.3 root 695: 1.1.1.6 root 696: A vector contains an arbitrary, specified number of pointers to 1.1.1.3 root 697: expressions. The number of elements in the vector is explicitly 1.1.1.7 ! root 698: present in the vector. The written form of a vector consists of square ! 699: brackets (`[...]') surrounding the elements, in sequence and with ! 700: whitespace separating them. Vectors of length zero are not created; ! 701: null pointers are used instead. 1.1.1.3 root 702: 1.1.1.6 root 703: Expressions are classified by "expression codes" (also called RTX 1.1.1.3 root 704: codes). The expression code is a name defined in `rtl.def', which is 1.1.1.7 ! root 705: also (in upper case) a C enumeration constant. The possible expression ! 706: codes and their meanings are machine-independent. The code of an RTX ! 707: can be extracted with the macro `GET_CODE (X)' and altered with ! 708: `PUT_CODE (X, NEWCODE)'. 1.1.1.3 root 709: 1.1.1.6 root 710: The expression code determines how many operands the expression 1.1.1.7 ! root 711: contains, and what kinds of objects they are. In RTL, unlike Lisp, you ! 712: cannot tell by looking at an operand what kind of object it is. 1.1.1.3 root 713: Instead, you must know from its context--from the expression code of 1.1.1.7 ! root 714: the containing expression. For example, in an expression of code ! 715: `subreg', the first operand is to be regarded as an expression and the ! 716: second operand as an integer. In an expression of code `plus', there ! 717: are two operands, both of which are to be regarded as expressions. In ! 718: a `symbol_ref' expression, there is one operand, which is to be ! 719: regarded as a string. 1.1.1.3 root 720: 1.1.1.6 root 721: Expressions are written as parentheses containing the name of the 1.1.1.3 root 722: expression type, its flags and machine mode if any, and then the 723: operands of the expression (separated by spaces). 724: 1.1.1.6 root 725: Expression code names in the `md' file are written in lower case, 1.1.1.7 ! root 726: but when they appear in C code they are written in upper case. In this ! 727: manual, they are shown as follows: `const_int'. 1.1.1.2 root 728: 1.1.1.6 root 729: In a few contexts a null pointer is valid where an expression is 1.1.1.3 root 730: normally wanted. The written form of this is `(nil)'. 1.1.1.2 root 731: 732: 1.1.1.3 root 733: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL 1.1.1.2 root 734: 1.1.1.3 root 735: Access to Operands 736: ================== 1.1.1.2 root 737: 1.1.1.7 ! root 738: For each expression type `rtl.def' specifies the number of contained ! 739: objects and their kinds, with four possibilities: `e' for expression ! 740: (actually a pointer to an expression), `i' for integer, `s' for string, ! 741: and `E' for vector of expressions. The sequence of letters for an ! 742: expression code is called its "format". Thus, the format of `subreg' ! 743: is `ei'. ! 744: ! 745: Two other format characters are used occasionally: `u' and `0'. `u' ! 746: is equivalent to `e' except that it is printed differently in debugging ! 747: dumps, and `0' means a slot whose contents do not fit any normal ! 748: category. `0' slots are not printed at all in dumps, and are often ! 749: used in special ways by small parts of the compiler. 1.1.1.3 root 750: 1.1.1.7 ! root 751: There are macros to get the number of operands and the format of an ! 752: expression code: 1.1.1.3 root 753: 754: `GET_RTX_LENGTH (CODE)' 755: Number of operands of an RTX of code CODE. 756: 757: `GET_RTX_FORMAT (CODE)' 758: The format of an RTX of code CODE, as a C string. 759: 1.1.1.7 ! root 760: Operands of expressions are accessed using the macros `XEXP', `XINT' ! 761: and `XSTR'. Each of these macros takes two arguments: an ! 762: expression-pointer (RTX) and an operand number (counting from zero). 1.1.1.3 root 763: Thus, 764: 765: XEXP (X, 2) 766: 767: accesses operand 2 of expression X, as an expression. 768: 769: XINT (X, 2) 770: 771: accesses the same operand as an integer. `XSTR', used in the same 772: fashion, would access it as a string. 773: 1.1.1.7 ! root 774: Any operand can be accessed as an integer, as an expression or as a ! 775: string. You must choose the correct method of access for the kind of ! 776: value actually stored in the operand. You would do this based on the ! 777: expression code of the containing expression. That is also how you ! 778: would know how many operands there are. ! 779: ! 780: For example, if X is a `subreg' expression, you know that it has two ! 781: operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, ! 782: 1)'. If you did `XINT (X, 0)', you would get the address of the ! 783: expression operand but cast as an integer; that might occasionally be ! 784: useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP ! 785: (X, 1)' would also compile without error, and would return the second, ! 786: integer operand cast as an expression pointer, which would probably ! 787: result in a crash when accessed. Nothing stops you from writing `XEXP ! 788: (X, 28)' either, but this will access memory past the end of the ! 789: expression with unpredictable results. 1.1.1.3 root 790: 1.1.1.6 root 791: Access to operands which are vectors is more complicated. You can 1.1.1.3 root 792: use the macro `XVEC' to get the vector-pointer itself, or the macros 793: `XVECEXP' and `XVECLEN' to access the elements and length of a vector. 794: 795: `XVEC (EXP, IDX)' 796: Access the vector-pointer which is operand number IDX in EXP. 797: 798: `XVECLEN (EXP, IDX)' 799: Access the length (number of elements) in the vector which is in 800: operand number IDX in EXP. This value is an `int'. 801: 802: `XVECEXP (EXP, IDX, ELTNUM)' 803: Access element number ELTNUM in the vector which is in operand 804: number IDX in EXP. This value is an RTX. 805: 806: It is up to you to make sure that ELTNUM is not negative and is 807: less than `XVECLEN (EXP, IDX)'. 808: 1.1.1.6 root 809: All the macros defined in this section expand into lvalues and 1.1.1.3 root 810: therefore can be used to assign the operands, lengths and vector 811: elements as well as to access them. 1.1.1.2 root 812: 813: 1.1.1.3 root 814: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL 1.1.1.2 root 815: 1.1.1.3 root 816: Flags in an RTL Expression 817: ========================== 1.1.1.2 root 818: 1.1.1.7 ! root 819: RTL expressions contain several flags (one-bit bit-fields) that are ! 820: used in certain types of expression. Most often they are accessed with ! 821: the following macros: 1.1.1.3 root 822: 1.1.1.4 root 823: `EXTERNAL_SYMBOL_P (X)' 824: In a `symbol_ref' expression, nonzero if it corresponds to a 825: variable declared extern in the users code. Zero for all other 826: variables. Stored in the `volatil' field and printed as `/v'. 827: 1.1.1.3 root 828: `MEM_VOLATILE_P (X)' 1.1.1.7 ! root 829: In `mem' expressions, nonzero for volatile memory references. 1.1.1.3 root 830: Stored in the `volatil' field and printed as `/v'. 831: 832: `MEM_IN_STRUCT_P (X)' 833: In `mem' expressions, nonzero for reference to an entire 834: structure, union or array, or to a component of one. Zero for 835: references to a scalar variable or through a pointer to a scalar. 836: Stored in the `in_struct' field and printed as `/s'. 837: 838: `REG_USER_VAR_P (X)' 1.1.1.7 ! root 839: In a `reg', nonzero if it corresponds to a variable present in the ! 840: user's source code. Zero for temporaries generated internally by ! 841: the compiler. Stored in the `volatil' field and printed as `/v'. 1.1.1.3 root 842: 843: `REG_FUNCTION_VALUE_P (X)' 844: Nonzero in a `reg' if it is the place in which this function's 845: value is going to be returned. (This happens only in a hard 846: register.) Stored in the `integrated' field and printed as `/i'. 847: 1.1.1.7 ! root 848: The same hard register may be used also for collecting the values ! 849: of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero ! 850: in this kind of use. 1.1.1.3 root 851: 852: `RTX_UNCHANGING_P (X)' 1.1.1.7 ! root 853: Nonzero in a `reg' or `mem' if the value is not changed explicitly ! 854: by the current function. (If it is a memory reference then it may ! 855: be changed by other functions or by aliasing.) Stored in the ! 856: `unchanging' field and printed as `/u'. 1.1.1.3 root 857: 858: `RTX_INTEGRATED_P (INSN)' 859: Nonzero in an insn if it resulted from an in-line function call. 1.1.1.7 ! root 860: Stored in the `integrated' field and printed as `/i'. This may be ! 861: deleted; nothing currently depends on it. 1.1.1.3 root 862: 863: `INSN_DELETED_P (INSN)' 864: In an insn, nonzero if the insn has been deleted. Stored in the 865: `volatil' field and printed as `/v'. 866: 867: `CONSTANT_POOL_ADDRESS_P (X)' 868: Nonzero in a `symbol_ref' if it refers to part of the current 1.1.1.4 root 869: function's "constants pool". These are addresses close to the 1.1.1.7 ! root 870: beginning of the function, and GNU CC assumes they can be addressed ! 871: directly (perhaps with the help of base registers). Stored in the ! 872: `unchanging' field and printed as `/u'. 1.1.1.3 root 873: 1.1.1.6 root 874: These are the fields which the above macros refer to: 1.1.1.3 root 875: 876: `used' 877: This flag is used only momentarily, at the end of RTL generation 1.1.1.7 ! root 878: for a function, to count the number of times an expression appears ! 879: in insns. Expressions that appear more than once are copied, ! 880: according to the rules for shared structure (*note Sharing::.). 1.1.1.3 root 881: 882: `volatil' 1.1.1.7 ! root 883: This flag is used in `mem',`symbol_ref' and `reg' expressions and ! 884: in insns. In RTL dump files, it is printed as `/v'. 1.1.1.3 root 885: 1.1.1.7 ! root 886: In a `mem' expression, it is 1 if the memory reference is volatile. ! 887: Volatile memory references may not be deleted, reordered or ! 888: combined. 1.1.1.3 root 889: 890: In a `reg' expression, it is 1 if the value is a user-level 1.1.1.7 ! root 891: variable. 0 indicates an internal compiler temporary. 1.1.1.3 root 892: 1.1.1.4 root 893: In a `symbol_ref' expression, it is 1 if the symbol is declared 894: `extern'. 895: 1.1.1.3 root 896: In an insn, 1 means the insn has been deleted. 897: 898: `in_struct' 899: This flag is used in `mem' expressions. It is 1 if the memory 1.1.1.7 ! root 900: datum referred to is all or part of a structure or array; 0 if it ! 901: is (or might be) a scalar variable. A reference through a C ! 902: pointer has 0 because the pointer might point to a scalar variable. 1.1.1.3 root 903: 1.1.1.7 ! root 904: This information allows the compiler to determine something about ! 905: possible cases of aliasing. 1.1.1.3 root 906: 907: In an RTL dump, this flag is represented as `/s'. 908: 909: `unchanging' 910: This flag is used in `reg' and `mem' expressions. 1 means that 911: the value of the expression never changes (at least within the 912: current function). 913: 914: In an RTL dump, this flag is represented as `/u'. 915: 916: `integrated' 1.1.1.7 ! root 917: In some kinds of expressions, including insns, this flag means the ! 918: rtl was produced by procedure integration. 1.1.1.3 root 919: 1.1.1.7 ! root 920: In a `reg' expression, this flag indicates the register containing ! 921: the value to be returned by the current function. On machines ! 922: that pass parameters in registers, the same register number may be ! 923: used for parameters as well, but this flag is not set on such uses. 1.1.1.2 root 924: 925: 1.1.1.3 root 926: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 1.1.1.2 root 927: 1.1.1.3 root 928: Machine Modes 929: ============= 1.1.1.2 root 930: 1.1.1.6 root 931: A machine mode describes a size of data object and the 932: representation used for it. In the C code, machine modes are 933: represented by an enumeration type, `enum machine_mode', defined in 1.1.1.7 ! root 934: `machmode.def'. Each RTL expression has room for a machine mode and so ! 935: do certain kinds of tree expressions (declarations and types, to be ! 936: precise). ! 937: ! 938: In debugging dumps and machine descriptions, the machine mode of an ! 939: RTL expression is written after the expression code with a colon to ! 940: separate them. The letters `mode' which appear at the end of each 1.1.1.3 root 941: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' 942: expression with machine mode `SImode'. If the mode is `VOIDmode', it 943: is not written at all. 944: 1.1.1.6 root 945: Here is a table of machine modes. 1.1.1.3 root 946: 947: `QImode' 1.1.1.4 root 948: "Quarter-Integer" mode represents a single byte treated as an 1.1.1.3 root 949: integer. 950: 951: `HImode' 1.1.1.4 root 952: "Half-Integer" mode represents a two-byte integer. 1.1.1.3 root 953: 954: `PSImode' 1.1.1.7 ! root 955: "Partial Single Integer" mode represents an integer which occupies ! 956: four bytes but which doesn't really use all four. On some ! 957: machines, this is the right mode to use for pointers. 1.1.1.3 root 958: 959: `SImode' 1.1.1.4 root 960: "Single Integer" mode represents a four-byte integer. 1.1.1.3 root 961: 962: `PDImode' 1.1.1.7 ! root 963: "Partial Double Integer" mode represents an integer which occupies ! 964: eight bytes but which doesn't really use all eight. On some ! 965: machines, this is the right mode to use for certain pointers. 1.1.1.3 root 966: 967: `DImode' 1.1.1.4 root 968: "Double Integer" mode represents an eight-byte integer. 1.1.1.3 root 969: 970: `TImode' 1.1.1.4 root 971: "Tetra Integer" (?) mode represents a sixteen-byte integer. 1.1.1.3 root 972: 973: `SFmode' 1.1.1.4 root 974: "Single Floating" mode represents a single-precision (four byte) 975: floating point number. 1.1.1.3 root 976: 977: `DFmode' 1.1.1.7 ! root 978: "Double Floating" mode represents a double-precision (eight byte) ! 979: floating point number. 1.1.1.3 root 980: 981: `XFmode' 1.1.1.4 root 982: "Extended Floating" mode represents a triple-precision (twelve 1.1.1.7 ! root 983: byte) floating point number. This mode is used for IEEE extended ! 984: floating point. 1.1.1.3 root 985: 986: `TFmode' 1.1.1.4 root 987: "Tetra Floating" mode represents a quadruple-precision (sixteen 988: byte) floating point number. 1.1.1.3 root 989: 990: `BLKmode' 1.1.1.7 ! root 991: "Block" mode represents values that are aggregates to which none of ! 992: the other modes apply. In RTL, only memory references can have ! 993: this mode, and only if they appear in string-move or vector 1.1.1.4 root 994: instructions. On machines which have no such instructions, 995: `BLKmode' will not appear in RTL. 1.1.1.3 root 996: 997: `VOIDmode' 1.1.1.7 ! root 998: Void mode means the absence of a mode or an unspecified mode. For ! 999: example, RTL expressions of code `const_int' have mode `VOIDmode' ! 1000: because they can be taken to have whatever mode the context ! 1001: requires. In debugging dumps of RTL, `VOIDmode' is expressed by ! 1002: the absence of any mode. 1.1.1.3 root 1003: 1004: `EPmode' 1.1.1.7 ! root 1005: "Entry Pointer" mode is intended to be used for function variables ! 1006: in Pascal and other block structured languages. Such values ! 1007: contain both a function address and a static chain pointer for ! 1008: access to automatic variables of outer levels. This mode is only ! 1009: partially implemented since C does not use it. 1.1.1.3 root 1010: 1011: `CSImode, ...' 1.1.1.4 root 1012: "Complex Single Integer" mode stands for a complex number 1.1.1.3 root 1013: represented as a pair of `SImode' integers. Any of the integer 1014: and floating modes may have `C' prefixed to its name to obtain a 1.1.1.7 ! root 1015: complex number mode. For example, there are `CQImode', `CSFmode', ! 1016: and `CDFmode'. Since C does not support complex numbers, these ! 1017: machine modes are only partially implemented. 1.1.1.3 root 1018: 1019: `BImode' 1.1.1.7 ! root 1020: This is the machine mode of a bit-field in a structure. It is used ! 1021: only in the syntax tree, never in RTL, and in the syntax tree it ! 1022: appears only in declaration nodes. In C, it appears only in ! 1023: `FIELD_DECL' nodes for structure fields defined with a bit size. 1.1.1.3 root 1024: 1.1.1.6 root 1025: The machine description defines `Pmode' as a C macro which expands 1.1.1.3 root 1026: into the machine mode used for addresses. Normally this is `SImode'. 1027: 1.1.1.6 root 1028: The only modes which a machine description must support are 1029: `QImode', `SImode', `SFmode' and `DFmode'. The compiler will attempt 1030: to use `DImode' for two-word structures and unions, but this can be 1.1.1.3 root 1031: prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. 1032: Likewise, you can arrange for the C type `short int' to avoid using 1033: `HImode'. In the long term it might be desirable to make the set of 1.1.1.7 ! root 1034: available machine modes machine-dependent and eliminate all assumptions ! 1035: about specific machine modes or their uses from the machine-independent ! 1036: code of the compiler. 1.1.1.3 root 1037: 1.1.1.7 ! root 1038: To help begin this process, the machine modes are divided into mode ! 1039: classes. These are represented by the enumeration type `enum 1.1.1.3 root 1040: mode_class' defined in `rtl.h'. The possible mode classes are: 1041: 1042: `MODE_INT' 1.1.1.7 ! root 1043: Integer modes. By default these are `QImode', `HImode', `SImode', ! 1044: `DImode', `TImode', and also `BImode'. 1.1.1.3 root 1045: 1046: `MODE_FLOAT' 1047: Floating-point modes. By default these are `QFmode', `HFmode', 1048: `SFmode', `DFmode' and `TFmode', but the MC68881 also defines 1049: `XFmode' to be an 80-bit extended-precision floating-point mode. 1050: 1051: `MODE_COMPLEX_INT' 1.1.1.7 ! root 1052: Complex integer modes. By default these are `CQImode', `CHImode', ! 1053: `CSImode', `CDImode' and `CTImode'. 1.1.1.3 root 1054: 1055: `MODE_COMPLEX_FLOAT' 1056: Complex floating-point modes. By default these are `CQFmode', 1057: `CHFmode', `CSFmode', `CDFmode' and `CTFmode', 1058: 1059: `MODE_FUNCTION' 1.1.1.7 ! root 1060: Algol or Pascal function variables including a static chain. 1.1.1.3 root 1061: (These are not currently implemented). 1062: 1063: `MODE_RANDOM' 1064: This is a catchall mode class for modes which don't fit into the 1065: above classes. Currently `VOIDmode', `BLKmode' and `EPmode' are 1066: in `MODE_RANDOM'. 1067: 1.1.1.6 root 1068: Here are some C macros that relate to machine modes: 1.1.1.3 root 1069: 1070: `GET_MODE (X)' 1071: Returns the machine mode of the RTX X. 1072: 1073: `PUT_MODE (X, NEWMODE)' 1074: Alters the machine mode of the RTX X to be NEWMODE. 1075: 1076: `NUM_MACHINE_MODES' 1077: Stands for the number of machine modes available on the target 1.1.1.7 ! root 1078: machine. This is one greater than the largest numeric value of any ! 1079: machine mode. 1.1.1.3 root 1080: 1081: `GET_MODE_NAME (M)' 1082: Returns the name of mode M as a string. 1083: 1084: `GET_MODE_CLASS (M)' 1085: Returns the mode class of mode M. 1086: 1087: `GET_MODE_SIZE (M)' 1088: Returns the size in bytes of a datum of mode M. 1089: 1090: `GET_MODE_BITSIZE (M)' 1091: Returns the size in bits of a datum of mode M. 1092: 1093: `GET_MODE_UNIT_SIZE (M)' 1.1.1.7 ! root 1094: Returns the size in bits of the subunits of a datum of mode M. ! 1095: This is the same as `GET_MODE_SIZE' except in the case of complex ! 1096: modes and `EPmode'. For them, the unit size is the size of the ! 1097: real or imaginary part, or the size of the function pointer or the ! 1098: context pointer. 1.1.1.2 root 1099: 1.1.1.6 root 1100:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.