home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 4 / FreshFish_May-June1994.bin / gnu / info / gcc.info-13 (.txt) < prev    next >
GNU Info File  |  1994-02-20  |  51KB  |  872 lines
  1. This is Info file gcc.info, produced by Makeinfo-1.55 from the input
  2. file gcc.texi.
  3.    This file documents the use and the internals of the GNU compiler.
  4.    Published by the Free Software Foundation 675 Massachusetts Avenue
  5. Cambridge, MA 02139 USA
  6.    Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
  7.    Permission is granted to make and distribute verbatim copies of this
  8. manual provided the copyright notice and this permission notice are
  9. preserved on all copies.
  10.    Permission is granted to copy and distribute modified versions of
  11. this manual under the conditions for verbatim copying, provided also
  12. that the sections entitled "GNU General Public License" and "Protect
  13. Your Freedom--Fight `Look And Feel'" are included exactly as in the
  14. original, and provided that the entire resulting derived work is
  15. distributed under the terms of a permission notice identical to this
  16.    Permission is granted to copy and distribute translations of this
  17. manual into another language, under the above conditions for modified
  18. versions, except that the sections entitled "GNU General Public
  19. License" and "Protect Your Freedom--Fight `Look And Feel'", and this
  20. permission notice, may be included in translations approved by the Free
  21. Software Foundation instead of in the original English.
  22. File: gcc.info,  Node: Insns,  Next: Calls,  Prev: Assembler,  Up: RTL
  23. Insns
  24. =====
  25.    The RTL representation of the code for a function is a doubly-linked
  26. chain of objects called "insns".  Insns are expressions with special
  27. codes that are used for no other purpose.  Some insns are actual
  28. instructions; others represent dispatch tables for `switch' statements;
  29. others represent labels to jump to or various sorts of declarative
  30. information.
  31.    In addition to its own specific data, each insn must have a unique
  32. id-number that distinguishes it from all other insns in the current
  33. function (after delayed branch scheduling, copies of an insn with the
  34. same id-number may be present in multiple places in a function, but
  35. these copies will always be identical and will only appear inside a
  36. `sequence'), and chain pointers to the preceding and following insns.
  37. These three fields occupy the same position in every insn, independent
  38. of the expression code of the insn.  They could be accessed with `XEXP'
  39. and `XINT', but instead three special macros are always used:
  40. `INSN_UID (I)'
  41.      Accesses the unique id of insn I.
  42. `PREV_INSN (I)'
  43.      Accesses the chain pointer to the insn preceding I.  If I is the
  44.      first insn, this is a null pointer.
  45. `NEXT_INSN (I)'
  46.      Accesses the chain pointer to the insn following I.  If I is the
  47.      last insn, this is a null pointer.
  48.    The first insn in the chain is obtained by calling `get_insns'; the
  49. last insn is the result of calling `get_last_insn'.  Within the chain
  50. delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must
  51. always correspond: if INSN is not the first insn,
  52.      NEXT_INSN (PREV_INSN (INSN)) == INSN
  53. is always true and if INSN is not the last insn,
  54.      PREV_INSN (NEXT_INSN (INSN)) == INSN
  55. is always true.
  56.    After delay slot scheduling, some of the insns in the chain might be
  57. `sequence' expressions, which contain a vector of insns.  The value of
  58. `NEXT_INSN' in all but the last of these insns is the next insn in the
  59. vector; the value of `NEXT_INSN' of the last insn in the vector is the
  60. same as the value of `NEXT_INSN' for the `sequence' in which it is
  61. contained.  Similar rules apply for `PREV_INSN'.
  62.    This means that the above invariants are not necessarily true for
  63. insns inside `sequence' expressions.  Specifically, if INSN is the
  64. first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn
  65. containing the `sequence' expression, as is the value of `PREV_INSN
  66. (NEXT_INSN (INSN))' is INSN is the last insn in the `sequence'
  67. expression.  You can use these expressions to find the containing
  68. `sequence' expression.
  69.    Every insn has one of the following six expression codes:
  70. `insn'
  71.      The expression code `insn' is used for instructions that do not
  72.      jump and do not do function calls.  `sequence' expressions are
  73.      always contained in insns with code `insn' even if one of those
  74.      insns should jump or do function calls.
  75.      Insns with code `insn' have four additional fields beyond the three
  76.      mandatory ones listed above.  These four are described in a table
  77.      below.
  78. `jump_insn'
  79.      The expression code `jump_insn' is used for instructions that may
  80.      jump (or, more generally, may contain `label_ref' expressions).  If
  81.      there is an instruction to return from the current function, it is
  82.      recorded as a `jump_insn'.
  83.      `jump_insn' insns have the same extra fields as `insn' insns,
  84.      accessed in the same way and in addition contains a field
  85.      `JUMP_LABEL' which is defined once jump optimization has completed.
  86.      For simple conditional and unconditional jumps, this field
  87.      contains the `code_label' to which this insn will (possibly
  88.      conditionally) branch.  In a more complex jump, `JUMP_LABEL'
  89.      records one of the labels that the insn refers to; the only way to
  90.      find the others is to scan the entire body of the insn.
  91.      Return insns count as jumps, but since they do not refer to any
  92.      labels, they have zero in the `JUMP_LABEL' field.
  93. `call_insn'
  94.      The expression code `call_insn' is used for instructions that may
  95.      do function calls.  It is important to distinguish these
  96.      instructions because they imply that certain registers and memory
  97.      locations may be altered unpredictably.
  98.      A `call_insn' insn may be preceded by insns that contain a single
  99.      `use' expression and be followed by insns the contain a single
  100.      `clobber' expression.  If so, these `use' and `clobber'
  101.      expressions are treated as being part of the function call.  There
  102.      must not even be a `note' between the `call_insn' and the `use' or
  103.      `clobber' insns for this special treatment to take place.  This is
  104.      somewhat of a kludge and will be removed in a later version of GNU
  105.      CC.
  106.      `call_insn' insns have the same extra fields as `insn' insns,
  107.      accessed in the same way.
  108. `code_label'
  109.      A `code_label' insn represents a label that a jump insn can jump
  110.      to.  It contains two special fields of data in addition to the
  111.      three standard ones.  `CODE_LABEL_NUMBER' is used to hold the
  112.      "label number", a number that identifies this label uniquely among
  113.      all the labels in the compilation (not just in the current
  114.      function).  Ultimately, the label is represented in the assembler
  115.      output as an assembler label, usually of the form `LN' where N is
  116.      the label number.
  117.      When a `code_label' appears in an RTL expression, it normally
  118.      appears within a `label_ref' which represents the address of the
  119.      label, as a number.
  120.      The field `LABEL_NUSES' is only defined once the jump optimization
  121.      phase is completed and contains the number of times this label is
  122.      referenced in the current function.
  123. `barrier'
  124.      Barriers are placed in the instruction stream when control cannot
  125.      flow past them.  They are placed after unconditional jump
  126.      instructions to indicate that the jumps are unconditional and
  127.      after calls to `volatile' functions, which do not return (e.g.,
  128.      `exit').  They contain no information beyond the three standard
  129.      fields.
  130. `note'
  131.      `note' insns are used to represent additional debugging and
  132.      declarative information.  They contain two nonstandard fields, an
  133.      integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
  134.      string accessed with `NOTE_SOURCE_FILE'.
  135.      If `NOTE_LINE_NUMBER' is positive, the note represents the
  136.      position of a source line and `NOTE_SOURCE_FILE' is the source
  137.      file name that the line came from.  These notes control generation
  138.      of line number data in the assembler output.
  139.      Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
  140.      code with one of the following values (and `NOTE_SOURCE_FILE' must
  141.      contain a null pointer):
  142.     `NOTE_INSN_DELETED'
  143.           Such a note is completely ignorable.  Some passes of the
  144.           compiler delete insns by altering