[PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt <bernds_cb1 at t-online dot de>]

This is a set of patches to convert m68k so that it no longer uses cc0.
The approach is to combine cc0 setter/user pairs into cbranch and cstore
patterns. It does not expose the flag register directly. Since m68k is a
target that is not under active development, and probably receives very
limited testing, I felt it was important to make it generate as close to
the same code as previously. Also, given that the target clobbers the
flags for pretty much every move, it seems unlikely that there's much
value to be had from anything more complex. Trying to model every
instruction's effect on the flags would be too error-prone for not
nearly enough gain.

The cc0 machinery allows for eliminating unnecessary comparisons by
examining the effect instructions have on the flags registers. I have
replicated that mechanism with a relatively modest amount of code based
on a final_postscan_insn hook, but it is now opt-in: an instruction
pattern can set the "flags_valid" attribute to a number of possible
values to indicate what effect it has. That should be more reliable (try
git log m68k.md to see recent sprinkling of CC_STATUS_INIT to squash
bugs with the previous mechanism).
We can remember either values where the flags indicate a comparison
against zero (after practically all arithmetic and move insns), or
alternatively record two comparison operands to eliminate identical
compares. I stopped adding optimizations once I found it hard to find
any meaningful differences in generated code. In particular, the
m68k.exp tests which verify that these optimizations are performed all
still pass.

Testing was done with the qemu-system-m68k/debian combination. I do not
have access to Coldfire hardware, and I tried to be somewhat
conservative, for example by not adding "flags_valid" everywhere it
would probably be possible. For someone with access to the hardware, it
should be trivial to add such attributes and test that everything still
works.
I'll have to rerun my final tests because test_summary made a mess of
things, but as far as I am able to tell, there are no regressions, and
the patch set even fixes some failures in libstdc++.

The first and second patch contain the m68k changes. They are separated
only to make the review easier, they were not tested separately (since
the time for a test run is measured in days). The first patch contains
preliminary cleanup and fixes, the second the main cc0 conversion. After
that, there are some changes in the rest of the compiler.


Bernd