This is the mail archive of the
mailing list for the GCC project.
Re: Overwhelmed by GCC frustration
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Georg-Johann Lay <avr at gjlay dot de>, Jeff Law <law at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 16 Aug 2017 23:23:27 +0900
- Subject: Re: Overwhelmed by GCC frustration
- Authentication-results: sourceware.org; auth=none
- References: <597F2FB4.firstname.lastname@example.org> <email@example.com> <20170731172340.GG13471@gate.crashing.org> <firstname.lastname@example.org> <email@example.com>
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
> "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
> 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
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.