Deprecating cc0 (and consequently cc0 targets)

[Jeff Law]

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