Remove CC0

This removes CC0 and all directly related infrastructure.

CC_STATUS, CC_STATUS_MDEP, CC_STATUS_MDEP_INIT, and NOTICE_UPDATE_CC
are deleted and poisoned.  CC0 is only deleted (some targets use that
name for something else).  HAVE_cc0 is automatically generated, and we
no longer will do that after this patch.

CC_STATUS_INIT is suggested in final.c to also be useful for ports that
are not CC0, and at least arm seems to use it for something.  So I am
leaving that alone, but most targets that have it could remove it.

2021-05-04  Segher Boessenkool  <segher@kernel.crashing.org>

	* caller-save.c: Remove CC0.
	* cfgcleanup.c: Remove CC0.
	* cfgrtl.c: Remove CC0.
	* combine.c: Remove CC0.
	* compare-elim.c: Remove CC0.
	* conditions.h: Remove CC0.
	* config/h8300/h8300.h: Remove CC0.
	* config/h8300/h8300-protos.h: Remove CC0.
	* config/h8300/peepholes.md: Remove CC0.
	* config/i386/x86-tune-sched.c: Remove CC0.
	* config/m68k/m68k.c: Remove CC0.
	* config/rl78/rl78.c: Remove CC0.
	* config/sparc/sparc.c: Remove CC0.
	* config/xtensa/xtensa.c: Remove CC0.
	(gen_conditional_move):  Use pc_rtx instead of cc0_rtx in a piece of
	RTL where that is used as a placeholder only.
	* cprop.c: Remove CC0.
	* cse.c: Remove CC0.
	* cselib.c: Remove CC0.
	* df-problems.c: Remove CC0.
	* df-scan.c: Remove CC0.
	* doc/md.texi: Remove CC0.  Adjust an example.
	* doc/rtl.texi: Remove CC0.  Adjust an example.
	* doc/tm.texi: Regenerate.
	* doc/tm.texi.in: Remove CC0.
	* emit-rtl.c: Remove CC0.
	* final.c: Remove CC0.
	* fwprop.c: Remove CC0.
	* gcse-common.c: Remove CC0.
	* gcse.c: Remove CC0.
	* genattrtab.c: Remove CC0.
	* genconfig.c: Remove CC0.
	* genemit.c: Remove CC0.
	* genextract.c: Remove CC0.
	* gengenrtl.c: Remove CC0.
	* genrecog.c: Remove CC0.
	* haifa-sched.c: Remove CC0.
	* ifcvt.c: Remove CC0.
	* ira-costs.c: Remove CC0.
	* ira.c: Remove CC0.
	* jump.c: Remove CC0.
	* loop-invariant.c: Remove CC0.
	* lra-constraints.c: Remove CC0.
	* lra-eliminations.c: Remove CC0.
	* optabs.c: Remove CC0.
	* postreload-gcse.c: Remove CC0.
	* postreload.c: Remove CC0.
	* print-rtl.c: Remove CC0.
	* read-rtl-function.c: Remove CC0.
	* reg-notes.def: Remove CC0.
	* reg-stack.c: Remove CC0.
	* reginfo.c: Remove CC0.
	* regrename.c: Remove CC0.
	* reload.c: Remove CC0.
	* reload1.c: Remove CC0.
	* reorg.c: Remove CC0.
	* resource.c: Remove CC0.
	* rtl.c: Remove CC0.
	* rtl.def: Remove CC0.
	* rtl.h: Remove CC0.
	* rtlanal.c: Remove CC0.
	* sched-deps.c: Remove CC0.
	* sched-rgn.c: Remove CC0.
	* shrink-wrap.c: Remove CC0.
	* simplify-rtx.c: Remove CC0.
	* system.h: Remove CC0.  Poison NOTICE_UPDATE_CC, CC_STATUS_MDEP_INIT,
	CC_STATUS_MDEP, and CC_STATUS.
	* target.def: Remove CC0.
	* valtrack.c: Remove CC0.
	* var-tracking.c: Remove CC0.

4 files changed, 39 insertions, 309 deletions

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index d166a0d..0e65b3a 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -7071,7 +7071,7 @@ such as
   [(set (pc)
         (if_then_else (match_operator
                          0 "comparison_operator"
-                         [(cc0) (const_int 0)])
+                         [(reg:CC CC_REG) (const_int 0)])
                       (return)
                       (pc)))]
   "@var{condition}"
@@ -7989,15 +7989,8 @@ works better when different sets of comparison operators are supported
 by different kinds of conditional branches (e.g.@: integer vs.@:
 floating-point), or by conditional branches with respect to conditional stores.
 
-Two separate insns are always used if the machine description represents
-a condition code register using the legacy RTL expression @code{(cc0)},
-and on most machines that use a separate condition code register
-(@pxref{Condition Code}).  For machines that use @code{(cc0)}, in
-fact, the set and use of the condition code must be separate and
-adjacent@footnote{@code{note} insns can separate them, though.}, thus
-allowing flags in @code{cc_status} to be used (@pxref{Condition Code}) and
-so that the comparison and branch insns could be located from each other
-by using the functions @code{prev_cc0_setter} and @code{next_cc0_user}.
+Two separate insns are always used on most machines that use a separate
+condition code register (@pxref{Condition Code}).
 
 Even in this case having a single entry point for conditional branches
 is advantageous, because it handles equally well the case where a single
@@ -8191,7 +8184,7 @@ the operations as far as possible.  For instance,
 @cindex @code{compare}, canonicalization of
 @item
 For the @code{compare} operator, a constant is always the second operand
-if the first argument is a condition code register or @code{(cc0)}.
+if the first argument is a condition code register.
 
 @item
 For instructions that inherently set a condition code register, the
@@ -9330,8 +9323,7 @@ In addition to describing the instruction supported by the target machine,
 the @file{md} file also defines a group of @dfn{attributes} and a set of
 values for each.  Every generated insn is assigned a value for each attribute.
 One possible attribute would be the effect that the insn has on the machine's
-condition code.  This attribute can then be used by @code{NOTICE_UPDATE_CC}
-to track the condition codes.
+condition code.
 
 @menu
 * Defining Attributes:: Specifying attributes and their values.
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index edbc60f..5af7113 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -1271,8 +1271,7 @@ accumulator.  The default format is ``64.64''.
 ``Condition Code'' mode represents the value of a condition code, which
 is a machine-specific set of bits used to represent the result of a
 comparison operation.  Other machine-specific modes may also be used for
-the condition code.  These modes are not used on machines that use
-@code{cc0} (@pxref{Condition Code}).
+the condition code.  (@pxref{Condition Code}).
 
 @findex BLKmode
 @item BLKmode
@@ -2324,60 +2323,17 @@ the reload pass.
 @code{scratch} is usually present inside a @code{clobber} operation
 (@pxref{Side Effects}).
 
-@findex cc0
-@cindex condition code register
-@item (cc0)
-This refers to the machine's condition code register.  It has no
-operands and may not have a machine mode.  There are two ways to use it:
-
-@itemize @bullet
-@item
-To stand for a complete set of condition code flags.  This is best on
-most machines, where each comparison sets the entire series of flags.
-
-With this technique, @code{(cc0)} may be validly used in only two
-contexts: as the destination of an assignment (in test and compare
-instructions) and in comparison operators comparing against zero
-(@code{const_int} with value zero; that is to say, @code{const0_rtx}).
-
-@item
-To stand for a single flag that is the result of a single condition.
-This is useful on machines that have only a single flag bit, and in
-which comparison instructions must specify the condition to test.
-
-With this technique, @code{(cc0)} may be validly used in only two
-contexts: as the destination of an assignment (in test and compare
-instructions) where the source is a comparison operator, and as the
-first operand of @code{if_then_else} (in a conditional branch).
-@end itemize
-
-@findex cc0_rtx
-There is only one expression object of code @code{cc0}; it is the
-value of the variable @code{cc0_rtx}.  Any attempt to create an
-expression of code @code{cc0} will return @code{cc0_rtx}.
-
-Instructions can set the condition code implicitly.  On many machines,
-nearly all instructions set the condition code based on the value that
-they compute or store.  It is not necessary to record these actions
-explicitly in the RTL because the machine description includes a
-prescription for recognizing the instructions that do so (by means of
-the macro @code{NOTICE_UPDATE_CC}).  @xref{Condition Code}.  Only
-instructions whose sole purpose is to set the condition code, and
-instructions that use the condition code, need mention @code{(cc0)}.
-
 On some machines, the condition code register is given a register number
-and a @code{reg} is used instead of @code{(cc0)}.  This is usually the
-preferable approach if only a small subset of instructions modify the
-condition code.  Other machines store condition codes in general
+and a @code{reg} is used.
+Other machines store condition codes in general
 registers; in such cases a pseudo register should be used.
 
 Some machines, such as the SPARC and RS/6000, have two sets of
 arithmetic instructions, one that sets and one that does not set the
 condition code.  This is best handled by normally generating the
 instruction that does not set the condition code, and making a pattern
-that both performs the arithmetic and sets the condition code register
-(which would not be @code{(cc0)} in this case).  For examples, search
-for @samp{addcc} and @samp{andcc} in @file{sparc.md}.
+that both performs the arithmetic and sets the condition code register.
+For examples, search for @samp{addcc} and @samp{andcc} in @file{sparc.md}.
 
 @findex pc
 @item (pc)
@@ -2495,14 +2451,13 @@ Of course, machines cannot really subtract with infinite precision.
 However, they can pretend to do so when only the sign of the result will
 be used, which is the case when the result is stored in the condition
 code.  And that is the @emph{only} way this kind of expression may
-validly be used: as a value to be stored in the condition codes, either
-@code{(cc0)} or a register.  @xref{Comparisons}.
+validly be used: as a value to be stored in the condition codes, in a
+register.  @xref{Comparisons}.
 
 The mode @var{m} is not related to the modes of @var{x} and @var{y}, but
-instead is the mode of the condition code value.  If @code{(cc0)} is
-used, it is @code{VOIDmode}.  Otherwise it is some mode in class
+instead is the mode of the condition code value.  It is some mode in class
 @code{MODE_CC}, often @code{CCmode}.  @xref{Condition Code}.  If @var{m}
-is @code{VOIDmode} or @code{CCmode}, the operation returns sufficient
+is @code{CCmode}, the operation returns sufficient
 information (in an unspecified format) so that any comparison operator
 can be applied to the result of the @code{COMPARE} operation.  For other
 modes in class @code{MODE_CC}, the operation only returns a subset of
@@ -2797,26 +2752,17 @@ of the data being compared.  If the comparison operation is being tested
 @code{VOIDmode}.
 
 @cindex condition codes
-There are two ways that comparison operations may be used.  The
-comparison operators may be used to compare the condition codes
-@code{(cc0)} against zero, as in @code{(eq (cc0) (const_int 0))}.  Such
-a construct actually refers to the result of the preceding instruction
-in which the condition codes were set.  The instruction setting the
-condition code must be adjacent to the instruction using the condition
-code; only @code{note} insns may separate them.
-
-Alternatively, a comparison operation may directly compare two data
+A comparison operation compares two data
 objects.  The mode of the comparison is determined by the operands; they
 must both be valid for a common machine mode.  A comparison with both
 operands constant would be invalid as the machine mode could not be
 deduced from it, but such a comparison should never exist in RTL due to
 constant folding.
 
-In the example above, if @code{(cc0)} were last set to
-@code{(compare @var{x} @var{y})}, the comparison operation is
-identical to @code{(eq @var{x} @var{y})}.  Usually only one style
+Usually only one style
 of comparisons is supported on a particular machine, but the combine
-pass will try to merge the operations to produce the @code{eq} shown
+pass will try to merge operations to produce code like
+@code{(eq @var{x} @var{y})},
 in case it exists in the context of the particular insn involved.
 
 Inequality comparisons come in two flavors, signed and unsigned.  Thus,
@@ -3168,7 +3114,7 @@ Represents the action of storing the value of @var{x} into the place
 represented by @var{lval}.  @var{lval} must be an expression
 representing a place that can be stored in: @code{reg} (or @code{subreg},
 @code{strict_low_part} or @code{zero_extract}), @code{mem}, @code{pc},
-@code{parallel}, or @code{cc0}.
+or @code{parallel}.
 
 If @var{lval} is a @code{reg}, @code{subreg} or @code{mem}, it has a
 machine mode; then @var{x} must be valid for that mode.
@@ -3191,13 +3137,6 @@ the bit-field (a memory or register reference) specified by the
 bit-field is not changed.  Note that @code{sign_extract} cannot
 appear in @var{lval}.
 
-If @var{lval} is @code{(cc0)}, it has no machine mode, and @var{x} may
-be either a @code{compare} expression or a value that may have any mode.
-The latter case represents a ``test'' instruction.  The expression
-@code{(set (cc0) (reg:@var{m} @var{n}))} is equivalent to
-@code{(set (cc0) (compare (reg:@var{m} @var{n}) (const_int 0)))}.
-Use the former expression to save space during the compilation.
-
 If @var{lval} is a @code{parallel}, it is used to represent the case of
 a function returning a structure in multiple registers.  Each element
 of the @code{parallel} is an @code{expr_list} whose first operand is a
@@ -3219,7 +3158,7 @@ does not jump) and the other of the two must be a @code{label_ref}
 @code{mem}; these unusual patterns are used to represent jumps through
 branch tables.
 
-If @var{lval} is neither @code{(cc0)} nor @code{(pc)}, the mode of
+If @var{lval} is not @code{(pc)}, the mode of
 @var{lval} must not be @code{VOIDmode} and the mode of @var{x} must be
 valid for the mode of @var{lval}.
 
@@ -3402,9 +3341,9 @@ For example, people sometimes attempt to represent a jump-if-zero
 instruction this way:
 
 @smallexample
-(parallel [(set (cc0) (reg:SI 34))
+(parallel [(set (reg:CC CC_REG) (reg:SI 34))
            (set (pc) (if_then_else
-                        (eq (cc0) (const_int 0))
+                        (eq (reg:CC CC_REG) (const_int 0))
                         (label_ref @dots{})
                         (pc)))])
 @end smallexample
@@ -3421,8 +3360,6 @@ whose elements are the operands needed to output the resulting
 assembler code---often @code{reg}, @code{mem} or constant expressions.
 This would not be well-formed RTL at any other stage in compilation,
 but it is OK then because no further optimization remains to be done.
-However, the definition of the macro @code{NOTICE_UPDATE_CC}, if
-any, must deal with such insns if you define any peephole optimizations.
 
 @findex cond_exec
 @item (cond_exec [@var{cond} @var{expr}])
@@ -4101,14 +4038,6 @@ In the debugging output, this field is printed as a number followed by
 a symbolic representation that locates the pattern in the @file{md}
 file as some small positive or negative offset from a named pattern.
 
-@findex LOG_LINKS
-@item LOG_LINKS (@var{i})
-A list (chain of @code{insn_list} expressions) giving information about
-dependencies between instructions within a basic block.  Neither a jump
-nor a label may come between the related insns.  These are only used by
-the schedulers and by combine.  This is a deprecated data structure.
-Def-use and use-def chains are now preferred.
-
 @findex REG_NOTES
 @item REG_NOTES (@var{i})
 A list (chain of @code{expr_list}, @code{insn_list} and @code{int_list}
@@ -4116,23 +4045,9 @@ expressions) giving miscellaneous information about the insn.  It is often
 information pertaining to the registers used in this insn.
 @end table
 
-The @code{LOG_LINKS} field of an insn is a chain of @code{insn_list}
-expressions.  Each of these has two operands: the first is an insn,
-and the second is another @code{insn_list} expression (the next one in
-the chain).  The last @code{insn_list} in the chain has a null pointer
-as second operand.  The significant thing about the chain is which
-insns appear in it (as first operands of @code{insn_list}
-expressions).  Their order is not significant.
-
-This list is originally set up by the flow analysis pass; it is a null
-pointer until then.  Flow only adds links for those data dependencies
-which can be used for instruction combination.  For each insn, the flow
-analysis pass adds a link to insns which store into registers values
-that are used for the first time in this insn.
-
-The @code{REG_NOTES} field of an insn is a chain similar to the
-@code{LOG_LINKS} field but it includes @code{expr_list} and @code{int_list}
-expressions in addition to @code{insn_list} expressions.  There are several
+The @code{REG_NOTES} field of an insn is a chain that includes
+@code{expr_list} and @code{int_list} expressions as well as @code{insn_list}
+expressions.  There are several
 kinds of register notes, which are distinguished by the machine mode, which
 in a register note is really understood as being an @code{enum reg_note}.
 The first operand @var{op} of the note is data whose meaning depends on
@@ -4147,8 +4062,7 @@ register note.  Its counterpart, the macro @code{PUT_REG_NOTE_KIND
 
 Register notes are of three classes: They may say something about an
 input to an insn, they may say something about an output of an insn, or
-they may create a linkage between two insns.  There are also a set
-of values that are only used in @code{LOG_LINKS}.
+they may create a linkage between two insns.
 
 These register notes annotate inputs to an insn:
 
@@ -4290,26 +4204,6 @@ insn has one of a pair of notes that points to a second insn, which has
 the inverse note pointing back to the first insn.
 
 @table @code
-@findex REG_CC_SETTER
-@findex REG_CC_USER
-@item REG_CC_SETTER
-@itemx REG_CC_USER
-On machines that use @code{cc0}, the insns which set and use @code{cc0}
-set and use @code{cc0} are adjacent.  However, when branch delay slot
-filling is done, this may no longer be true.  In this case a
-@code{REG_CC_USER} note will be placed on the insn setting @code{cc0} to
-point to the insn using @code{cc0} and a @code{REG_CC_SETTER} note will
-be placed on the insn using @code{cc0} to point to the insn setting
-@code{cc0}.
-@end table
-
-These values are only used in the @code{LOG_LINKS} field, and indicate
-the type of dependency that each link represents.  Links which indicate
-a data dependence (a read after write dependence) do not use any code,
-they simply have mode @code{VOIDmode}, and are printed without any
-descriptive text.
-
-@table @code
 @findex REG_DEP_TRUE
 @item REG_DEP_TRUE
 This indicates a true dependence (a read after write dependence).
@@ -5272,10 +5166,6 @@ are shared.
 @item
 There is only one @code{pc} expression.
 
-@cindex @code{cc0}, RTL sharing
-@item
-There is only one @code{cc0} expression.
-
 @cindex @code{const_double}, RTL sharing
 @item
 There is only one @code{const_double} expression with value 0 for
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 7e8fb8b..5f27309 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6310,21 +6310,16 @@ or target-specific sections.
 @section Condition Code Status
 @cindex condition code status
 
-The macros in this section can be split in two families, according to the
-two ways of representing condition codes in GCC.
-
-The first representation is the so called @code{(cc0)} representation
-(@pxref{Jump Patterns}), where all instructions can have an implicit
-clobber of the condition codes.  The second is the condition code
-register representation, which provides better schedulability for
+Condition codes in GCC are represented as registers,
+which provides better schedulability for
 architectures that do have a condition code register, but on which
 most instructions do not affect it.  The latter category includes
 most RISC machines.
 
-The implicit clobbering poses a strong restriction on the placement of
+Implicit clobbering would pose a strong restriction on the placement of
 the definition and use of the condition code.  In the past the definition
 and use were always adjacent.  However, recent changes to support trapping
-arithmatic may result in the definition and user being in different blocks.
+arithmetic may result in the definition and user being in different blocks.
 Thus, there may be a @code{NOTE_INSN_BASIC_BLOCK} between them.  Additionally,
 the definition may be the source of exception handling edges.
 
@@ -6335,8 +6330,7 @@ three instructions earlier than the conditional branch.  The instruction
 scheduler cannot perform this optimization if it is not permitted to
 separate the definition and use of the condition code register.
 
-For this reason, it is possible and suggested to use a register to
-represent the condition code for new ports.  If there is a specific
+If there is a specific
 condition code register in the machine, use a hard register.  If the
 condition code or comparison result can be placed in any general register,
 or if there are multiple condition registers, use a pseudo register.
@@ -6348,78 +6342,9 @@ specified already in the compare instruction.  In this case, you are not
 interested in most macros in this section.
 
 @menu
-* CC0 Condition Codes::      Old style representation of condition codes.
 * MODE_CC Condition Codes::  Modern representation of condition codes.
 @end menu
 
-@node CC0 Condition Codes
-@subsection Representation of condition codes using @code{(cc0)}
-@findex cc0
-
-@findex cc_status
-The file @file{conditions.h} defines a variable @code{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 @code{CC_STATUS_MDEP}.
-
-@defmac CC_STATUS_MDEP
-C code for a data type which is used for declaring the @code{mdep}
-component of @code{cc_status}.  It defaults to @code{int}.
-
-This macro is not used on machines that do not use @code{cc0}.
-@end defmac
-
-@defmac CC_STATUS_MDEP_INIT
-A C expression to initialize the @code{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 @code{cc0}.
-@end defmac
-
-@defmac NOTICE_UPDATE_CC (@var{exp}, @var{insn})
-A C compound statement to set the components of @code{cc_status}
-appropriately for an insn @var{insn} whose body is @var{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 @code{(cc0)}.
-
-This macro is not used on machines that do not use @code{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
-@code{NOTICE_UPDATE_CC} can leave @code{cc_status} unaltered for such
-insns.  But suppose that the previous insn set the condition code
-based on location @samp{a4@@(102)} and the current insn stores a new
-value in @samp{a4}.  Although the condition code is not changed by
-this, it will no longer be true that it reflects the contents of
-@samp{a4@@(102)}.  Therefore, @code{NOTICE_UPDATE_CC} must alter
-@code{cc_status} in this case to say that nothing is known about the
-condition code value.
-
-The definition of @code{NOTICE_UPDATE_CC} must be prepared to deal
-with the results of peephole optimization: insns whose patterns are
-@code{parallel} RTXs containing various @code{reg}, @code{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
-@code{NOTICE_UPDATE_CC} should do when it sees one is just to run
-@code{CC_STATUS_INIT}.
-
-A possible definition of @code{NOTICE_UPDATE_CC} is to call a function
-that looks at an attribute (@pxref{Insn Attributes}) named, for example,
-@samp{cc}.  This avoids having detailed information about patterns in
-two places, the @file{md} file and in @code{NOTICE_UPDATE_CC}.
-@end defmac
-
 @node MODE_CC Condition Codes
 @subsection Representation of condition codes using registers
 @findex CCmode
@@ -6534,7 +6459,7 @@ like:
 @end defmac
 
 @deftypefn {Target Hook} bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *@var{p1}, unsigned int *@var{p2})
-On targets which do not use @code{(cc0)}, and which use a hard
+On targets which use a hard
 register rather than a pseudo-register to hold condition codes, the
 regular CSE passes are often not able to identify cases in which the
 hard register is set to a common value.  Use this hook to enable a
@@ -11578,8 +11503,7 @@ for cross-profiling.
 
 A C expression for the maximum number of instructions to execute via
 conditional execution instructions instead of a branch.  A value of
-@code{BRANCH_COST}+1 is the default if the machine does not use cc0, and
-1 if it does use cc0.
+@code{BRANCH_COST}+1 is the default.
 @end defmac
 
 @defmac IFCVT_MODIFY_TESTS (@var{ce_info}, @var{true_expr}, @var{false_expr})
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 20acf36..d8e3de1 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4268,21 +4268,16 @@ or @code{TARGET_MAX_ANCHOR_OFFSET} is set to a nonzero value.
 @section Condition Code Status
 @cindex condition code status
 
-The macros in this section can be split in two families, according to the
-two ways of representing condition codes in GCC.
-
-The first representation is the so called @code{(cc0)} representation
-(@pxref{Jump Patterns}), where all instructions can have an implicit
-clobber of the condition codes.  The second is the condition code
-register representation, which provides better schedulability for
+Condition codes in GCC are represented as registers,
+which provides better schedulability for
 architectures that do have a condition code register, but on which
 most instructions do not affect it.  The latter category includes
 most RISC machines.
 
-The implicit clobbering poses a strong restriction on the placement of
+Implicit clobbering would pose a strong restriction on the placement of
 the definition and use of the condition code.  In the past the definition
 and use were always adjacent.  However, recent changes to support trapping
-arithmatic may result in the definition and user being in different blocks.
+arithmetic may result in the definition and user being in different blocks.
 Thus, there may be a @code{NOTE_INSN_BASIC_BLOCK} between them.  Additionally,
 the definition may be the source of exception handling edges.
 
@@ -4293,8 +4288,7 @@ three instructions earlier than the conditional branch.  The instruction
 scheduler cannot perform this optimization if it is not permitted to
 separate the definition and use of the condition code register.
 
-For this reason, it is possible and suggested to use a register to
-represent the condition code for new ports.  If there is a specific
+If there is a specific
 condition code register in the machine, use a hard register.  If the
 condition code or comparison result can be placed in any general register,
 or if there are multiple condition registers, use a pseudo register.
@@ -4306,78 +4300,9 @@ specified already in the compare instruction.  In this case, you are not
 interested in most macros in this section.
 
 @menu
-* CC0 Condition Codes::      Old style representation of condition codes.
 * MODE_CC Condition Codes::  Modern representation of condition codes.
 @end menu
 
-@node CC0 Condition Codes
-@subsection Representation of condition codes using @code{(cc0)}
-@findex cc0
-
-@findex cc_status
-The file @file{conditions.h} defines a variable @code{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 @code{CC_STATUS_MDEP}.
-
-@defmac CC_STATUS_MDEP
-C code for a data type which is used for declaring the @code{mdep}
-component of @code{cc_status}.  It defaults to @code{int}.
-
-This macro is not used on machines that do not use @code{cc0}.
-@end defmac
-
-@defmac CC_STATUS_MDEP_INIT
-A C expression to initialize the @code{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 @code{cc0}.
-@end defmac
-
-@defmac NOTICE_UPDATE_CC (@var{exp}, @var{insn})
-A C compound statement to set the components of @code{cc_status}
-appropriately for an insn @var{insn} whose body is @var{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 @code{(cc0)}.
-
-This macro is not used on machines that do not use @code{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
-@code{NOTICE_UPDATE_CC} can leave @code{cc_status} unaltered for such
-insns.  But suppose that the previous insn set the condition code
-based on location @samp{a4@@(102)} and the current insn stores a new
-value in @samp{a4}.  Although the condition code is not changed by
-this, it will no longer be true that it reflects the contents of
-@samp{a4@@(102)}.  Therefore, @code{NOTICE_UPDATE_CC} must alter
-@code{cc_status} in this case to say that nothing is known about the
-condition code value.
-
-The definition of @code{NOTICE_UPDATE_CC} must be prepared to deal
-with the results of peephole optimization: insns whose patterns are
-@code{parallel} RTXs containing various @code{reg}, @code{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
-@code{NOTICE_UPDATE_CC} should do when it sees one is just to run
-@code{CC_STATUS_INIT}.
-
-A possible definition of @code{NOTICE_UPDATE_CC} is to call a function
-that looks at an attribute (@pxref{Insn Attributes}) named, for example,
-@samp{cc}.  This avoids having detailed information about patterns in
-two places, the @file{md} file and in @code{NOTICE_UPDATE_CC}.
-@end defmac
-
 @node MODE_CC Condition Codes
 @subsection Representation of condition codes using registers
 @findex CCmode
@@ -7909,8 +7834,7 @@ for cross-profiling.
 
 A C expression for the maximum number of instructions to execute via
 conditional execution instructions instead of a branch.  A value of
-@code{BRANCH_COST}+1 is the default if the machine does not use cc0, and
-1 if it does use cc0.
+@code{BRANCH_COST}+1 is the default.
 @end defmac
 
 @defmac IFCVT_MODIFY_TESTS (@var{ce_info}, @var{true_expr}, @var{false_expr})