On 9/20/19 11:22 AM, Richard Biener wrote: > On September 20, 2019 5:38:38 PM GMT+02:00, Jeff Law <l...@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
