This is the mail archive of the
mailing list for the GCC project.
Re: Deprecating cc0 (and consequently cc0 targets)
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 <firstname.lastname@example.org> 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.