This is the mail archive of the
mailing list for the GCC project.
Re: Deprecating cc0 (and consequently cc0 targets)
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Cc: Denis Chertykov <chertykov at gmail dot com>, hp at axis dot com, Andreas Schwab <schwab at linux-m68k dot org>, Matt Thomas <matt at 3am-software dot com>
- Date: Fri, 20 Sep 2019 11:45:05 -0600
- Subject: Re: Deprecating cc0 (and consequently cc0 targets)
- References: <email@example.com> <3D71D7C0-1155-4B1C-822F-3B3D49134DC7@gmail.com>
On 9/20/19 11:22 AM, Richard Biener wrote:
> On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law <firstname.lastname@example.org>
>> At the register allocation BOF during the Cauldron someone (I
>> forget who) raised the question of when/how do we get rid of
>> The first step in that process is to drop support for cc0. cc0 is
>> a horribly antiquated mechanism for describing how to handle
>> condition codes. It has numerous limitations, the most
>> problematical being the requirement that the cc0 setter and cc0
>> user must be consecutive in the IL. This requirement bleeds all
>> over the compiler resulting in code that is harder to understand
>> and maintain. I'm fairly confident this code is broken in various
>> ways, particularly WRT exceptions.
>> So this message is serving as official notice that we are
>> *deprecating* all cc0 support in gcc-10. We are not removing any
>> code or targets at this time -- removals would happen during the
>> gcc-11 cycle.
>> avr cris h8300 m68k vax cr16
>> This is based on actually looking at the backend patterns.
>> backends.html indicates the mn103 port would be affected, but I
>> think it's just out-of-date. Similarly it fails to mention cr16,
>> but cr16 clearly has affected patterns (I'll address that
>> This patch deprecates the affected targets. With some magic folks
>> can continue to build them. However, if nobody steps forward to
>> convert them from cc0 to MODE_CC those targets will be removed
>> during the gcc-11 cycle.
>> If someone is interested in possibly doing a conversion, I would
>> strongly recommend reviewing the best documentation we have on the
>> I worked with my son about a year ago to transition the v850 to
>> MODE_CC using that page as a guideline. We also have a partial
>> transition for the H8/300 port (not far enough to even build
>> anything yet). I had hoped we would finish the H8/300 port last
>> year and would have tackled another, but events have gotten in the
>> The transition isn't terribly hard, but does take time because of
>> the number of patterns that have to be changed.
>> Let the discussion begin...
> It seems to be that for the goal to keep a target alive a variant #2
> conversion (according to the wiki) should be closely mirror CC0
> behavior and thus should be easier to achieve and with less patterns
> touched than the 'good' variant. Can you acknowledge that and would
> such 'simple' conversions be OK?
Unless the target has condition code preserving arithmetic a variant #2
conversion is the only way to go.
Now if someone did a variant #2 without the optimization bits (ie,
adding appropriate _set_flags pattern variants), I think that should be
considered explicitly OK even though the code quality would potentially
suffer. Essentially it's a choice between dropping the port or keeping
the port, but with slightly less optimization. THe latter seems like a
better choice to me.