On September 22, 2019 1:48:34 AM GMT+02:00, Segher Boessenkool <seg...@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 <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?
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
