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