Deprecating cc0 (and consequently cc0 targets)
diff mbox series

Message ID 1ee03bc0-ad1a-46dd-87bb-8288e990ce20@redhat.com
State New
Headers show
Series
  • Deprecating cc0 (and consequently cc0 targets)
Related show

Commit Message

Jeff Law Sept. 20, 2019, 3:38 p.m. UTC
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.


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 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 gcc-11
cycle.

If someone is interested in possibly doing a conversion, I would
strongly recommend reviewing the best documentation we have on the subject:

https://gcc.gnu.org/wiki/CC0Transition

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...


Jeff

Comments

Richard Biener Sept. 20, 2019, 5:22 p.m. UTC | #1
On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law <law@redhat.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.
>
>
>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 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
>gcc-11
>cycle.
>
>If someone is interested in possibly doing a conversion, I would
>strongly recommend reviewing the best documentation we have on the
>subject:
>
>https://gcc.gnu.org/wiki/CC0Transition
>
>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? 

Richard. 

>
>Jeff
Joseph Myers Sept. 20, 2019, 5:24 p.m. UTC | #2
I think the m68k-*-uclinuxoldabi* and vax-*-vms* cases need to move up to 
the top of that case statement (duplicating the "not supported" error), to 
keep that error even in the --enable-obsolete case.

I see tile* targets are referenced in the diff context.  They were 
obsoleted in GCC 8 (and have also been removed from glibc and the Linux 
kernel), isn't it time to remove them?
Jeff Law Sept. 20, 2019, 5:45 p.m. UTC | #3
On 9/20/19 11:22 AM, Richard Biener wrote:
> On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law <law@redhat.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.
>> 
>> 
>> 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
>> 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 gcc-11 cycle.
>> 
>> If someone is interested in possibly doing a conversion, I would 
>> strongly recommend reviewing the best documentation we have on the 
>> subject:
>> 
>> https://gcc.gnu.org/wiki/CC0Transition
>> 
>> 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?
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.

jeff
Paul Koning Sept. 21, 2019, 8:48 p.m. UTC | #4
> On Sep 20, 2019, at 1:45 PM, Jeff Law <law@redhat.com> wrote:
> 
> On 9/20/19 11:22 AM, Richard Biener wrote:
>> ...
>> 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.

Yes.

> 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.

True.  Then again, the added work of creating the pattern pairs is modest.  With define_subst, much of the work can be automated.

For pdp11, I found this to be the case; the hard part was to learn what is needed, and for that the Wiki ends up a big help.  Also, pdp11 is harder than most because it has two CC registers (one for float ops, one for the rest).  I don't know all the others, but for example VAX only has one, and I'm pretty sure the same applies to m68k.

	paul
Jeff Law Sept. 21, 2019, 9:04 p.m. UTC | #5
On 9/21/19 2:48 PM, Paul Koning wrote:
> 
> 
>> On Sep 20, 2019, at 1:45 PM, Jeff Law <law@redhat.com> wrote:
>> 
>> On 9/20/19 11:22 AM, Richard Biener wrote:
>>> ... 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.
> 
> Yes.
> 
>> 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.
> 
> True.  Then again, the added work of creating the pattern pairs is
> modest.  With define_subst, much of the work can be automated.
The patterns and support to handle optimization can be added after the
basic conversion is done.  In fact, that's precisely how I'd approach it.


> 
> For pdp11, I found this to be the case; the hard part was to learn
> what is needed, and for that the Wiki ends up a big help.  Also,
> pdp11 is harder than most because it has two CC registers (one for
> float ops, one for the rest).  I don't know all the others, but for
> example VAX only has one, and I'm pretty sure the same applies to
> m68k.
m68k is like pdp11 in this regard.  Two condition code registers, one in
the main processor and another for the 68881 FP unit.


jeff
Segher Boessenkool Sept. 21, 2019, 11:48 p.m. UTC | #6
On Sat, Sep 21, 2019 at 03:04:26PM -0600, Jeff Law wrote:
> On 9/21/19 2:48 PM, Paul Koning wrote:
> >> On Sep 20, 2019, at 1:45 PM, Jeff Law <law@redhat.com> wrote:
> >> On 9/20/19 11:22 AM, Richard Biener wrote:
> >> 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.
> > 
> > True.  Then again, the added work of creating the pattern pairs is
> > modest.  With define_subst, much of the work can be automated.
> The patterns and support to handle optimization can be added after the
> basic conversion is done.  In fact, that's precisely how I'd approach it.

Yeah, but a type #2 conversion is more than that; it makes it harder to
do a type #1 conversion later than if you started with doing just that.
Of course it is better than totally dropping a target.  Some coordination
would be useful.

OTOH, a type #2 conversion seems easy enough that maybe we can just pull
that off for *all* targets for GCC 10, and actually remove CC0 already?

> > For pdp11, I found this to be the case; the hard part was to learn
> > what is needed, and for that the Wiki ends up a big help.  Also,
> > pdp11 is harder than most because it has two CC registers (one for
> > float ops, one for the rest).  I don't know all the others, but for
> > example VAX only has one, and I'm pretty sure the same applies to
> > m68k.
> m68k is like pdp11 in this regard.  Two condition code registers, one in
> the main processor and another for the 68881 FP unit.

I think the main difficulty with m68k is that it is a pretty big target.


Segher
Maya Rashish Sept. 22, 2019, 10:44 a.m. UTC | #7
On Fri, Sep 20, 2019 at 09:38:38AM -0600, Jeff Law wrote:
> this time -- removals would happen during the gcc-11 cycle.

Hi Jeff,

I'm concerned that if I don't reach this milestone for VAX, it'll mean
that future code review will require justifying some of the original
changes which is getting increasingly challenging.

My first attempt at a CCmode conversion crashes early, and I was
suggested to first address any known bugs. I'll take another shot at it.
Richard Biener Sept. 22, 2019, 12:02 p.m. UTC | #8
On September 22, 2019 1:48:34 AM GMT+02:00, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>On Sat, Sep 21, 2019 at 03:04:26PM -0600, Jeff Law wrote:
>> On 9/21/19 2:48 PM, Paul Koning wrote:
>> >> On Sep 20, 2019, at 1:45 PM, Jeff Law <law@redhat.com> wrote:
>> >> On 9/20/19 11:22 AM, Richard Biener wrote:
>> >> 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.
>> > 
>> > True.  Then again, the added work of creating the pattern pairs is
>> > modest.  With define_subst, much of the work can be automated.
>> The patterns and support to handle optimization can be added after
>the
>> basic conversion is done.  In fact, that's precisely how I'd approach
>it.
>
>Yeah, but a type #2 conversion is more than that; it makes it harder to
>do a type #1 conversion later than if you started with doing just that.
>Of course it is better than totally dropping a target.  Some
>coordination
>would be useful.
>
>OTOH, a type #2 conversion seems easy enough that maybe we can just
>pull
>that off for *all* targets for GCC 10, and actually remove CC0 already?

That was exactly my thinking... 

>> > For pdp11, I found this to be the case; the hard part was to learn
>> > what is needed, and for that the Wiki ends up a big help.  Also,
>> > pdp11 is harder than most because it has two CC registers (one for
>> > float ops, one for the rest).  I don't know all the others, but for
>> > example VAX only has one, and I'm pretty sure the same applies to
>> > m68k.
>> m68k is like pdp11 in this regard.  Two condition code registers, one
>in
>> the main processor and another for the 68881 FP unit.
>
>I think the main difficulty with m68k is that it is a pretty big
>target.
>
>
>Segher

Patch
diff mbox series

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 69d0a024d85..0c1637e8be1 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,6 +248,12 @@  md_file=
 # Obsolete configurations.
 case ${target} in
   tile*-*-*				\
+  avr*-*-*				\
+  h8300*-*-*				\
+  cris*-*-*				\
+  m68k*-*-*				\
+  vax*-*-*				\
+  cr16*-*-*				\
  )
     if test "x$enable_obsolete" != xyes; then
       echo "*** Configuration ${target} is obsolete." >&2
@@ -273,7 +279,6 @@  case ${target} in
  | arm*-*-uclinux*			\
  | i[34567]86-go32-*			\
  | i[34567]86-*-go32*			\
- | m68k-*-uclinuxoldabi*		\
  | mips64orion*-*-rtems*		\
  | pdp11-*-bsd				\
  | powerpc*-*-linux*paired*		\
@@ -294,7 +299,6 @@  case ${target} in
  | *-*-solaris2.[0-9].*			\
  | *-*-solaris2.10*			\
  | *-*-sysv*				\
- | vax-*-vms*				\
  )
 	echo "*** Configuration ${target} not supported" 1>&2
 	exit 1