This is the mail archive of the
mailing list for the GCC project.
Re: Deprecating cc0 (and consequently cc0 targets)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: gcc-patches at gcc dot gnu dot org,Jeff Law <law at redhat dot com>,gcc-patches <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 19:22:36 +0200
- Subject: Re: Deprecating cc0 (and consequently cc0 targets)
- References: <firstname.lastname@example.org>
On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law <email@example.com> wrote:
>At the register allocation BOF during the Cauldron someone (I forget
>who) raised the question of when/how do we get rid of reload.
>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.
>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 separately)
>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
>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 way.
>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?