home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 8 / FreshFishVol8-CD1.bin / gnu / info / gcc.info-21 (.txt) < prev    next >
GNU Info File  |  1994-12-22  |  46KB  |  788 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, 1994 Free Software Foundation,
  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," "Funding for
  13. Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
  14. included exactly as in the original, and provided that the entire
  15. resulting derived work is distributed under the terms of a permission
  16. notice identical to this one.
  17.    Permission is granted to copy and distribute translations of this
  18. manual into another language, under the above conditions for modified
  19. versions, except that the sections entitled "GNU General Public
  20. License," "Funding for Free Software," and "Protect Your Freedom--Fight
  21. `Look And Feel'", and this permission notice, may be included in
  22. translations approved by the Free Software Foundation instead of in the
  23. original English.
  24. File: gcc.info,  Node: Condition Code,  Next: Costs,  Prev: Addressing Modes,  Up: Target Macros
  25. Condition Code Status
  26. =====================
  27.    This describes the condition code status.
  28.    The file `conditions.h' defines a variable `cc_status' to describe
  29. how the condition code was computed (in case the interpretation of the
  30. condition code depends on the instruction that it was set by).  This
  31. variable contains the RTL expressions on which the condition code is
  32. currently based, and several standard flags.
  33.    Sometimes additional machine-specific flags must be defined in the
  34. machine description header file.  It can also add additional
  35. machine-specific information by defining `CC_STATUS_MDEP'.
  36. `CC_STATUS_MDEP'
  37.      C code for a data type which is used for declaring the `mdep'
  38.      component of `cc_status'.  It defaults to `int'.
  39.      This macro is not used on machines that do not use `cc0'.
  40. `CC_STATUS_MDEP_INIT'
  41.      A C expression to initialize the `mdep' field to "empty".  The
  42.      default definition does nothing, since most machines don't use the
  43.      field anyway.  If you want to use the field, you should probably
  44.      define this macro to initialize it.
  45.      This macro is not used on machines that do not use `cc0'.
  46. `NOTICE_UPDATE_CC (EXP, INSN)'
  47.      A C compound statement to set the components of `cc_status'
  48.      appropriately for an insn INSN whose body is EXP.  It is this
  49.      macro's responsibility to recognize insns that set the condition
  50.      code as a byproduct of other activity as well as those that
  51.      explicitly set `(cc0)'.
  52.      This macro is not used on machines that do not use `cc0'.
  53.      If there are insns that do not set the condition code but do alter
  54.      other machine registers, this macro must check to see whether they
  55.      invalidate the expressions that the condition code is recorded as
  56.      reflecting.  For example, on the 68000, insns that store in address
  57.      registers do not set the condition code, which means that usually
  58.      `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
  59.      But suppose that the previous insn set the condition code based
  60.      on location `a4@(102)' and the current insn stores a new value in
  61.      `a4'.  Although the condition code is not changed by this, it will
  62.      no longer be true that it reflects the contents of `a4@(102)'.
  63.      Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
  64.      to say that nothing is known about the condition code value.
  65.      The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
  66.      the results of peephole optimization: insns whose patterns are
  67.      `parallel' RTXs containing various `reg', `mem' or constants which
  68.      are just the operands.  The RTL structure of these insns is not
  69.      sufficient to indicate what the insns actually do.  What
  70.      `NOTICE_UPDATE_CC' should do when it sees one is just to run
  71.      `CC_STATUS_INIT'.
  72.      A possible definition of `NOTICE_UPDATE_CC' is to call a function
  73.      that looks at an attribute (*note Insn Attributes::.) named, for
  74.      example, `cc'.  This avoids having detailed information about
  75.      patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
  76. `EXTRA_CC_MODES'
  77.      A list of names to be used for additional modes for condition code
  78.      values in registers (*note Jump Patterns::.).  These names are
  79.      added to `enum machine_mode' and all have class `MODE_CC'.  By
  80.      convention, they should start with `CC' and end with `mode'.
  81.      You should only define this macro if your machine does not use
  82.      `cc0' and only if additional modes are required.
  83. `EXTRA_CC_NAMES'
  84.      A list of C strings giving the names for the modes listed in
  85.      `EXTRA_CC_MODES'.  For example, the Sparc defines this macro and
  86.      `EXTRA_CC_MODES' as
  87.           #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode
  88.           #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE"
  89.      This macro is not required if `EXTRA_CC_MODES' is not defined.
  90. `SELECT_CC_MODE (OP, X, Y)'
  91.      Returns a mode from class `MODE_CC' to be used when comparison
  92.      operation code OP is applied to rtx X and Y.  For example, on the
  93.      Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::.
  94.      for a description of the reason for this definition)
  95.           #define SELECT_CC_MODE(OP,X,Y) \
  96.             (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT          \
  97.              ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode)    \
  98.              : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS    \
  99.                  || GET_CODE (X) == NEG) \
  100.                 ? CC_NOOVmode : CCmode))
  101.      You need not define this macro if `EXTRA_CC_MODES' is not defined.
  102. `CANONICALIZE_COMPARISON (CODE, OP0, OP1)'
  103.      One some machines not all possible comparisons are defined, but
  104.      you can convert an invalid comparison into a valid one.  For
  105.      example, the Alpha does not have a `GT' comparison, but you can
  106.      use an `LT' comparison instead and swap the order of the operands.
  107.      On such machines, define this macro to be a C statement to do any
  108.      required conversions.  CODE is the initial comparison code and OP0
  109.      and OP1 are the left and right operands of the comparison,
  110.      respectively.  You should modify CODE, OP0, and OP1 as required.
  111.      GNU CC will not assume that the comparison resulting from this
  112.      macro is valid but will see if the resulting insn matches a
  113.      pattern in the `md' file.
  114.      You need not define this macro if it would never change the
  115.      comparison code or operands.
  116. `REVERSIBLE_CC_MODE (MODE)'
  117.      A C expression whose value is one if it is always safe to reverse a
  118.      comparison whose mode is MODE.  If `SELECT_CC_MODE' can ever
  119.      return MODE for a floating-point inequality comparison, then
  120.      `REVERSIBLE_CC_MODE (MODE)' must be zero.
  121.      You need not define this macro if it would always returns zero or
  122.      if the floating-point format is anything other than
  123.      `IEEE_FLOAT_FORMAT'.  For example, here is the definition used on
  124.      the Sparc, where floating-point inequality comparisons are always
  125.      given `CCFPEmode':
  126.           #define REVERSIBLE_CC_MODE(MODE)  ((MODE) != CCFPEmode)
  127. File: gcc.info,  Node: Costs,  Next: Sections,  Prev: Condition Code,  Up: Target Macros
  128. Describing Relative Costs of Operations
  129. =======================================
  130.    These macros let you describe the relative speed of various
  131. operations on the target machine.
  132. `CONST_COSTS (X, CODE, OUTER_CODE)'
  133.      A part of a C `switch' statement that describes the relative costs
  134.      of constant RTL expressions.  It must contain `case' labels for
  135.      expression codes `const_int', `const', `symbol_ref', `label_ref'
  136.      and `const_double'.  Each case must ultimately reach a `return'
  137.      statement to return the relative cost of the use of that kind of
  138.      constant