On 11/13/19 6:04 AM, Bernd Schmidt wrote: > 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. I tend to agree. My only worry would be introducing a new way to deal with cc0. But I'll certainly look at the changes with an open mind.
It might play well with ideas I had while looking at the H8 port which has a very similar model. > > 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). Yea, sounds like a reimplementation of the tst elimination bits, but buried in the backend. Given the choice of dropping the port or burying this kind of stuff in there, I'd lean towards accepting the latter. > 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. Yea. One of the things I was pondering was dropping many/most of the combiner patterns then only adding those back which were clearly still important. I have a strong suspicion we have *many* unnecessary patterns. Of course finding those may be more work than its worth. > > 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'm happy to add your patch to my tester. It'll verify the compiler bootstraps and can build glibc & the kernel. Jeff ps. On a more personal note -- good to hear from you Bernd. I hope things are going well.
