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