home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 5 / FreshFish_July-August1994.bin / bbs / gnu / gcc-2.5.8-bin.lha / info / gcc.info-20 (.txt) < prev    next >
GNU Info File  |  1994-07-11  |  49KB  |  831 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: Condition Code,  Next: Costs,  Prev: Addressing Modes,  Up: Target Macros
  23. Condition Code Status
  24. =====================
  25.    The file `conditions.h' defines a variable `cc_status' to describe
  26. how the condition code was computed (in case the interpretation of the
  27. condition code depends on the instruction that it was set by).  This
  28. variable contains the RTL expressions on which the condition code is
  29. currently based, and several standard flags.
  30.    Sometimes additional machine-specific flags must be defined in the
  31. machine description header file.  It can also add additional
  32. machine-specific information by defining `CC_STATUS_MDEP'.
  33. `CC_STATUS_MDEP'
  34.      C code for a data type which is used for declaring the `mdep'
  35.      component of `cc_status'.  It defaults to `int'.
  36.      This macro is not used on machines that do not use `cc0'.
  37. `CC_STATUS_MDEP_INIT'
  38.      A C expression to initialize the `mdep' field to "empty".  The
  39.      default definition does nothing, since most machines don't use the
  40.      field anyway.  If you want to use the field, you should probably
  41.      define this macro to initialize it.
  42.      This macro is not used on machines that do not use `cc0'.
  43. `NOTICE_UPDATE_CC (EXP, INSN)'
  44.      A C compound statement to set the components of `cc_status'
  45.      appropriately for an insn INSN whose body is EXP.  It is this
  46.      macro's responsibility to recognize insns that set the condition
  47.      code as a byproduct of other activity as well as those that
  48.      explicitly set `(cc0)'.
  49.      This macro is not used on machines that do not use `cc0'.
  50.      If there are insns that do not set the condition code but do alter
  51.      other machine registers, this macro must check to see whether they
  52.      invalidate the expressions that the condition code is recorded as
  53.      reflecting.  For example, on the 68000, insns that store in address
  54.      registers do not set the condition code, which means that usually
  55.      `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
  56.      But suppose that the previous insn set the condition code based
  57.      on location `a4@(102)' and the current insn stores a new value in
  58.      `a4'.  Although the condition code is not changed by this, it will
  59.      no longer be true that it reflects the contents of `a4@(102)'.
  60.      Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
  61.      to say that nothing is known about the condition code value.
  62.      The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
  63.      the results of peephole optimization: insns whose patterns are
  64.      `parallel' RTXs containing various `reg', `mem' or constants which
  65.      are just the operands.  The RTL structure of these insns is not
  66.      sufficient to indicate what the insns actually do.  What
  67.      `NOTICE_UPDATE_CC' should do when it sees one is just to run
  68.      `CC_STATUS_INIT'.
  69.      A possible definition of `NOTICE_UPDATE_CC' is to call a function
  70.      that looks at an attribute (*note Insn Attributes::.) named, for
  71.      example, `cc'.  This avoids having detailed information about
  72.      patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
  73. `EXTRA_CC_MODES'
  74.      A list of names to be used for additional modes for condition code
  75.      values in registers (*note Jump Patterns::.).  These names are
  76.      added to `enum machine_mode' and all have class `MODE_CC'.  By
  77.      convention, they should start with `CC' and end with `mode'.
  78.      You should only define this macro if your machine does not use
  79.      `cc0' and only if additional modes are required.
  80. `EXTRA_CC_NAMES'
  81.      A list of C strings giving the names for the modes listed in
  82.      `EXTRA_CC_MODES'.  For example, the Sparc defines this macro and
  83.      `EXTRA_CC_MODES' as
  84.           #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode
  85.           #define EXTRA_CC_NAMES "CC_NOOV", "CCFP"
  86.      This macro is not required if `EXTRA_CC_MODES' is not defined.
  87. `SELECT_CC_MODE (OP, X, Y)'
  88.      Returns a mode from class `MODE_CC' to be used when comparison
  89.      operation code OP is applied to rtx X and Y.  For example, on the
  90.      Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::.
  91.      for a description of the reason for this definition)
  92.           #define SELECT_CC_MODE(OP,X,Y) \
  93.             (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT          \
  94.              ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode)    \
  95.              : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS    \
  96.                  || GET_CODE (X) == NEG) \
  97.                 ? CC_NOOVmode : CCmode))
  98.      This macro is not required if `EXTRA_CC_MODES' is not defined.
  99. File: gcc.info,  Node: Costs,  Next: Sections,  Prev: Condition Code,  Up: Target Macros
  100. Describing Relative Costs of Operations
  101. =======================================
  102.    These macros let you describe the relative speed of various
  103. operations on the target machine.
  104. `CONST_COSTS (X, CODE, OUTER_CODE)'
  105.      A part of a C `switch' statement that describes the relative costs
  106.      of constant RTL expressions.  It must contain `case' labels for
  107.      expression codes `const_int', `const', `symbol_ref', `label_ref'
  108.      and `const_double'.  Each case must ultimately reach a `return'
  109.      statement to return the relative cost of the use of that kind of
  110.      constant value in an expression.  The cost may depend on the
  111.      precise value of the constant, which is available for examination
  112.      in X, and the rtx code of the expression in which it is contained,
  113.      found in OUTER_CODE.
  114.      CODE is the expression code--redundant, since it can be obtained
  115.      with `GET_CODE (X)'.
  116. `RTX_COSTS (X, CODE, OUTER_CODE)'
  117.      Like `CONST_COSTS' but applies to nonconstant RTL expressions.
  118.      This can be used, for example, to indicate how costly a multiply
  119.      instruction is.  In writing this macro, you can use the construct
  120.      `COSTS_N_INSNS (N)' to specify a cost equal to N fast
  121.      instructions.  OUTER_CODE is the code of the expression in which X
  122.      is contained.
  123.      This macro is optional; do not define it if the default cost
  124.      assumptions are adequate for the target machine.
  125. `ADDRESS_COST (ADDRESS)'
  126.      An expression giving the cost of an addressing mode that contains
  127.      ADDRESS.  If not defined, the cost is computed from the ADDRESS
  128.      expression and the `CONST_COSTS' values.
  129.      For most CISC machines, the default cost is a good approximation
  130.      of the true cost of the addressing mode.  However, on RISC
  131.      machines, all instructions normally have the same length and
  132.      execution time.  Hence all addresses will have equal costs.
  133.      In cases where more than one form of an address is known, the form
  134.      with the lowest cost will be used.  If multiple forms have the
  135.      same, lowest, cost, the one that is the most complex will be used.
  136.      For example, suppose an address that is equal to the sum of a
  137.      register and a constant is used twice in th