This describes the condition code status.
The file `conditions.h' defines a variable
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. It defaults to
int. This macro is not used on machines that do not use
mdepfield 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
NOTICE_UPDATE_CC (exp, insn)
cc_statusappropriately 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
cc_statusunaltered 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,
cc_statusin this case to say that nothing is known about the condition code value. The definition of
NOTICE_UPDATE_CCmust be prepared to deal with the results of peephole optimization: insns whose patterns are
parallelRTXs containing various
memor 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_CCshould do when it sees one is just to run
CC_STATUS_INIT. A possible definition of
NOTICE_UPDATE_CCis 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
enum machine_modeand 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
cc0and only if additional modes are required.
EXTRA_CC_MODES. For example, the Sparc defines this macro and
#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE"This macro is not required if
EXTRA_CC_MODESis not defined.
SELECT_CC_MODE (op, x, y)
MODE_CCto be used when comparison operation code op is applied to rtx x and y. For example, on the Sparc,
SELECT_CC_MODEis 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_MODESis not defined.
CANONICALIZE_COMPARISON (code, op0, op1)
GTcomparison, but you can use an
LTcomparison 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.
SELECT_CC_MODEcan 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
#define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)