gccint: CC0 Condition Codes

1 
1 18.15.1 Representation of condition codes using '(cc0)'
1 -------------------------------------------------------
1 
1 The file 'conditions.h' defines a variable 'cc_status' to describe how
1 the condition code was computed (in case the interpretation of the
1 condition code depends on the instruction that it was set by).  This
1 variable contains the RTL expressions on which the condition code is
1 currently based, and several standard flags.
1 
1  Sometimes additional machine-specific flags must be defined in the
1 machine description header file.  It can also add additional
1 machine-specific information by defining 'CC_STATUS_MDEP'.
1 
1  -- Macro: CC_STATUS_MDEP
1      C code for a data type which is used for declaring the 'mdep'
1      component of 'cc_status'.  It defaults to 'int'.
1 
1      This macro is not used on machines that do not use 'cc0'.
1 
1  -- Macro: CC_STATUS_MDEP_INIT
1      A C expression to initialize the 'mdep' field to "empty".  The
1      default definition does nothing, since most machines don't use the
1      field anyway.  If you want to use the field, you should probably
1      define this macro to initialize it.
1 
1      This macro is not used on machines that do not use 'cc0'.
1 
1  -- Macro: NOTICE_UPDATE_CC (EXP, INSN)
1      A C compound statement to set the components of 'cc_status'
1      appropriately for an insn INSN whose body is EXP.  It is this
1      macro's responsibility to recognize insns that set the condition
1      code as a byproduct of other activity as well as those that
1      explicitly set '(cc0)'.
1 
1      This macro is not used on machines that do not use 'cc0'.
1 
1      If there are insns that do not set the condition code but do alter
1      other machine registers, this macro must check to see whether they
1      invalidate the expressions that the condition code is recorded as
1      reflecting.  For example, on the 68000, insns that store in address
1      registers do not set the condition code, which means that usually
1      'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns.
1      But suppose that the previous insn set the condition code based on
1      location 'a4@(102)' and the current insn stores a new value in
1      'a4'.  Although the condition code is not changed by this, it will
1      no longer be true that it reflects the contents of 'a4@(102)'.
1      Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case
1      to say that nothing is known about the condition code value.
1 
1      The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with
1      the results of peephole optimization: insns whose patterns are
1      'parallel' RTXs containing various 'reg', 'mem' or constants which
1      are just the operands.  The RTL structure of these insns is not
1      sufficient to indicate what the insns actually do.  What
1      'NOTICE_UPDATE_CC' should do when it sees one is just to run
1      'CC_STATUS_INIT'.
1 
1      A possible definition of 'NOTICE_UPDATE_CC' is to call a function
1      that looks at an attribute (⇒Insn Attributes) named, for
1      example, 'cc'.  This avoids having detailed information about
1      patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'.
1