Re: H8 cc0 conversion

[Hans-Peter Nilsson <hp@bitrange.com>]

On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
> This is the primary patch for cc0 removal on the H8 port.? It doesn't
> have any of the optimization work and many patterns are simply disabled
> at this time.? It's working well enough to not regress the testsuite.
>
> The H8 is similar to the m68k and other ports in that the vast majority
> of instructions clobber the condition codes, including most of the
> arithmetic insns that reload needs to use. While there's a special
> adds/subs that does not modify the condition codes, they only accept
> constant addends of 1, 2 and 4. With that in mind, this port does not
> expose cc0 until after reload. So most patterns are defined using
> define_insn_and_split. The splitter adds the appropriate clobbers.

JFTR (as I'm repeating a previous note for another port): if
you'd went for exposing cc0 *before* reload (adding a clobber to
each pattern that clobbers, then specifying exceptions removing
them), the amount of (required) define_insn_and_splits would
have been zero; typically much less churn in the port.  That
approach also has the benefit of insns not "silently" changing
behavior at reload-time.

You might think a parallel with a clobber for each insn hampers
some rtl optimizations, but I found that to be not an issue at
all, doing that for CRIS (at least when comparing to the cc0
version).

brgds, H-P