Stefan Franke <ste...@franke.ms> writes: > Am 2019-12-08 01:54, schrieb Oleg Endo: >> On Tue, 2019-11-26 at 07:38 +0100, ste...@franke.ms wrote: >>> > On 11/21/19 10:30 AM, ste...@franke.ms wrote: >>> > > Hi there, >>> > > >>> > > here is mc68k's patch to switch the m68k architecture over to ccmode >>> > > and >>> > > lra. See https://github.com/mc68kghost/gcc 68k-ccmode branch. >>> > >>> > Bernd Schmidt posted a conversion of the m68k port to ccmode a couple >>> > weeks before yours. We've already ACK'd it for installing onto the >>> > trunk. >>> > >>> > Jeff >>> >>> To be honest: >>> - 8 days is hardly "a couple weeks before" >>> - ccmode is not the same as ccmode+lra >>> >>> The paperwork for contributing to fsf is on the way and the repo at >>> https://github.com/mc68kghost/gcc got an update. Tests are not yet at >>> 100% >>> (master branch fails too many tests) but it's closer to master branch >>> now. >>> The code is to 50% identical, a fair amount has swapped cmp/bcc, few >>> are a >>> tad worse and some yield surprisingly better code. >>> >> >> You can still submit patches for further improvements, like adding >> support for LRA. Now that the main CCmode conversion is on trunk and >> has been confirmed and tested, it should be much easier for you to >> pinpoint problems in your changes. >> >> Cheers, >> Oleg > > The problems are in the gcc implementation > > - the lra implementation is buggy > - the compare elimination can't handle parallel's containing a compare > - df-core considers parallel's containing a compare also as a USE > - some optimizations/mechanisms do only work if HAVE_CC0 is defined > - way more ... > > And the current implementation is IMHO unusable for lra since it did not > introduce a CC register to track clobbering. So it's a dead end.
I'm not sure about this last bit. LRA simply isn't set up to cope with move instructions that could clobber the CC register, so on targets like m68k, I think we'd want to hide any CC register until after LRA anyway. Having a CC register could be useful for post-RA optimisation, but not having one shouldn't affect the choice of RA. (To be clear: this is in reply to the above two lines only. Thanks for doing this work, and especially for considering the transition to LRA. I doubt it will be long before we deprecate all targets that require old reload.) Richard > > I can live with the fact that my patch was refuted since I simply use my > *working* fork, where I fixed the issues mentioned above. > > /cheers > Stefan
