This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

[PATCH 0/4] Eliminate cc0 from m68k

From: Bernd Schmidt <bernds_cb1 at t-online dot de>

To: GCC Patches <gcc-patches at gcc dot gnu dot org>

Date: Wed, 13 Nov 2019 14:04:59 +0100

Subject: [PATCH 0/4] Eliminate cc0 from m68k

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