CC0 Condition Codes - GNU Compiler Collection (GCC) Internals
Description: GNU Compiler Collection (GCC) Internals

Next: MODE_CC Condition Codes, Up: Condition Code

#### 17.16.1 Representation of condition codes using `(cc0)`

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`.

— Macro: 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`.

— Macro: 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`.

— Macro: 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 Insn Attributes) named, for example, ‘`cc`’. This avoids having detailed information about patterns in two places, the `md` file and in `NOTICE_UPDATE_CC`.