GNU Info

Info Node: (gcc-300.info)Condition Code

(gcc-300.info)Condition Code


Next: Costs Prev: Addressing Modes Up: Target Macros
Enter node , (file) or (file)node

Condition Code Status
=====================

   This describes the condition code status.

   The file `conditions.h' defines a variable `cc_status' to describe
how the condition code was computed (in case the interpretation of the
condition code depends on the instruction that it was set by).  This
variable contains the RTL expressions on which the condition code is
currently based, and several standard flags.

   Sometimes additional machine-specific flags must be defined in the
machine description header file.  It can also add additional
machine-specific information by defining `CC_STATUS_MDEP'.

`CC_STATUS_MDEP'
     C code for a data type which is used for declaring the `mdep'
     component of `cc_status'.  It defaults to `int'.

     This macro is not used on machines that do not use `cc0'.

`CC_STATUS_MDEP_INIT'
     A C expression to initialize the `mdep' field to "empty".  The
     default definition does nothing, since most machines don't use the
     field anyway.  If you want to use the field, you should probably
     define this macro to initialize it.

     This macro is not used on machines that do not use `cc0'.

`NOTICE_UPDATE_CC (EXP, INSN)'
     A C compound statement to set the components of `cc_status'
     appropriately for an insn INSN whose body is EXP.  It is this
     macro's responsibility to recognize insns that set the condition
     code as a byproduct of other activity as well as those that
     explicitly set `(cc0)'.

     This macro is not used on machines that do not use `cc0'.

     If there are insns that do not set the condition code but do alter
     other machine registers, this macro must check to see whether they
     invalidate the expressions that the condition code is recorded as
     reflecting.  For example, on the 68000, insns that store in address
     registers do not set the condition code, which means that usually
     `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
     But suppose that the previous insn set the condition code based
     on location `a4@(102)' and the current insn stores a new value in
     `a4'.  Although the condition code is not changed by this, it will
     no longer be true that it reflects the contents of `a4@(102)'.
     Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
     to say that nothing is known about the condition code value.

     The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
     the results of peephole optimization: insns whose patterns are
     `parallel' RTXs containing various `reg', `mem' or constants which
     are just the operands.  The RTL structure of these insns is not
     sufficient to indicate what the insns actually do.  What
     `NOTICE_UPDATE_CC' should do when it sees one is just to run
     `CC_STATUS_INIT'.

     A possible definition of `NOTICE_UPDATE_CC' is to call a function
     that looks at an attribute (Note: Insn Attributes) named, for
     example, `cc'.  This avoids having detailed information about
     patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.

`EXTRA_CC_MODES'
     A list of additional modes for condition code values in registers
     (Note: Jump Patterns).  This macro should expand to a sequence of
     calls of the macro `CC' separated by white space.  `CC' takes two
     arguments.  The first is the enumeration name of the mode, which
     should begin with `CC' and end with `mode'.  The second is a C
     string giving the printable name of the mode; it should be the
     same as the first argument, but with the trailing `mode' removed.

     You should only define this macro if additional modes are required.

     A sample definition of `EXTRA_CC_MODES' is:
          #define EXTRA_CC_MODES            \
              CC(CC_NOOVmode, "CC_NOOV")    \
              CC(CCFPmode, "CCFP")          \
              CC(CCFPEmode, "CCFPE")

`SELECT_CC_MODE (OP, X, Y)'
     Returns a mode from class `MODE_CC' to be used when comparison
     operation code OP is applied to rtx X and Y.  For example, on the
     Sparc, `SELECT_CC_MODE' is defined as (see Note: Jump Patterns
     for a description of the reason for this definition)

          #define SELECT_CC_MODE(OP,X,Y) \
            (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT          \
             ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode)    \
             : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS    \
                 || GET_CODE (X) == NEG) \
                ? CC_NOOVmode : CCmode))

     You need not define this macro if `EXTRA_CC_MODES' is not defined.

`CANONICALIZE_COMPARISON (CODE, OP0, OP1)'
     On some machines not all possible comparisons are defined, but you
     can convert an invalid comparison into a valid one.  For example,
     the Alpha does not have a `GT' comparison, but you can use an `LT'
     comparison instead and swap the order of the operands.

     On such machines, define this macro to be a C statement to do any
     required conversions.  CODE is the initial comparison code and OP0
     and OP1 are the left and right operands of the comparison,
     respectively.  You should modify CODE, OP0, and OP1 as required.

     GCC will not assume that the comparison resulting from this macro
     is valid but will see if the resulting insn matches a pattern in
     the `md' file.

     You need not define this macro if it would never change the
     comparison code or operands.

`REVERSIBLE_CC_MODE (MODE)'
     A C expression whose value is one if it is always safe to reverse a
     comparison whose mode is MODE.  If `SELECT_CC_MODE' can ever
     return MODE for a floating-point inequality comparison, then
     `REVERSIBLE_CC_MODE (MODE)' must be zero.

     You need not define this macro if it would always returns zero or
     if the floating-point format is anything other than
     `IEEE_FLOAT_FORMAT'.  For example, here is the definition used on
     the Sparc, where floating-point inequality comparisons are always
     given `CCFPEmode':

          #define REVERSIBLE_CC_MODE(MODE)  ((MODE) != CCFPEmode)

     A C expression whose value is reversed condition code of the CODE
     for comparison done in CC_MODE MODE.  The macro is used only in
     case `REVERSIBLE_CC_MODE (MODE)' is nonzero.  Define this macro in
     case machine has some non-standard way how to reverse certain
     conditionals.  For instance in case all floating point conditions
     are non-trapping, compiler may freely convert unordered compares
     to ordered one.  Then definition may look like:

          #define REVERSE_CONDITION(CODE, MODE) \
             ((MODE) != CCFPmode ? reverse_condition (CODE) \
              : reverse_condition_maybe_unordered (CODE))


automatically generated by info2www version 1.2.2.9