This is the mail archive of the
mailing list for the GCC project.
Re: Overwhelmed by GCC frustration
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: Jeff Law <law at redhat dot com>, Oleg Endo <oleg dot endo at t-online dot de>, gcc at gcc dot gnu dot org
- Date: Wed, 16 Aug 2017 16:58:49 -0500
- 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, Aug 16, 2017 at 03:53:24PM +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".
_All_ cc0 backends. We cannot remove cc0 support without removing all
targets that depend on it.
The push for moving away from cc0 isn't anything new.
> First of all, LRA cannot cope with cc0 (Yes, I know deprecating
> cc0 is just to deprecate all non-LRA BEs).
No, it isn't that at all. CC0 is problematic in very many places. It
is a blocker for removing old reload, that is true.
> As far as cc0 is concerned, transforming avr BE is not trivial.
That unfortunately is true for all cc0 backends. It requires looking
over all of the backend code (not just the MD files even), and it
requires knowing the actual target behaviour in detail.
And it cannot be done piecemeal, it's an all-or-nothing switch.
> But my feeling is that opposing deprecation of cc0 is futile,
> the voices that support cc0 deprecation are more and usefulness
> of cc0 is not recognized.
> Sooner or later these backends will end up in /dev/null.
If they aren't converted, yes.
A more constructive question is: what can be done to make conversion
easier and less painful?