On Wed, 2017-08-16 at 15:53 +0200, Georg-Johann Lay wrote: > > This means it's actually waste of time to work on these > backends. The code will finally end up in the dustbin as cc0 > backends are considered undesired ballast that has to be > "jettisoned". > > "Deprecate all cc0" is just a nice formulation of "deprecate > most of the cc0 backends". > > Just the fact that the backends that get most attention and attract > most developers don't use cc0 doesn't mean cc0 is a useless device.
The desire to get rid of old, crusty and unmaintained stuff is somehow understandable... > First of all, LRA cannot cope with cc0 (Yes, I know deprecating > cc0 is just to deprecate all non-LRA BEs). LRA asserts that > accessing the frame doesn't change condition code. LRA doesn't > provide replacement for LEGITIMITE_RELOAD_ADDRESS. Hence LRA > focusses just comfortable, orthogonal targets. It seems LRA is being praised so much, but all those niche BEs and corner cases get zero support. There are several known instances of SH code regressions with LRA, and that's why I haven't switched it to LRA. I think the problem is that it's very difficult to make a register allocator that works well for everything. The last attempt ended in reload. And eventually LRA will go down the same route. So instead of trying to fit a round peg in a square hole, maybe we should just have the options for round and square pegs and holes. Cheers, Oleg
