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 (see section Instruction 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 names to be used for additional modes for condition code values in registers (see section Defining Jump Instruction Patterns). These names are added to enum machine_mode and all have class MODE_CC. By convention, they should start with `CC' and end with `mode'. You should only define this macro if your machine does not use cc0 and only if additional modes are required.

EXTRA_CC_NAMES

A list of C strings giving the names for the modes listed in EXTRA_CC_MODES. For example, the Sparc defines this macro and EXTRA_CC_MODES as

#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode
#define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE"

This macro is not required if EXTRA_CC_MODES is not defined.

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 see section Defining Jump Instruction 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)

One 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. GNU CC 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)

Go to the first, previous, next, last section, table of contents.