Deprecating cc0 (and consequently cc0 targets)

[Segher Boessenkool]

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