Status of m32c target?

[Georg-Johann Lay]

On 13.01.2018 00:07, Joseph Myers wrote:
> On Fri, 12 Jan 2018, Jeff Law wrote:
> 
>> I was going to suggest deprecation for gcc-8 given how badly it was
>> broken in gcc-7 and the lack of maintenance on the target.
> 
> While we're considering deprecations, what happened to the idea of setting
> a timescale by which cc0 targets need to be converted away from cc0 or be
> removed?

I still don't quite get why cc0 is considered to be so bad.  Just the 
fact that the big targets don't use it doesn't make it useless.

Yes, I know that CCmode can represent condition code.  But just the fact 
that it can represent it doesn't make it superior or cc0 inferior or 
bad.  Having different representations for the same thing has also its 
obvious upsides (think of different representations in maths or 
physics), and in the present case one has the choice between an explicit 
RTL representation and an implicit (w.r.t. to RTL) one.

The target I am familiar with is avr, and for that particular target, I 
cannot see a single benefit:

- cc0 does a good job and did always a good job in the past. In the 
years I contributed to avr, there hasn't been a single cc0 flaw (all the 
few, minor cc0-related issues were avr BE issues).  From my experience, 
if some middle-end bits flaw for a what-the-dickens-is-xxx-target, then 
that target is left behind and has to hack the backend to surmount the 
middle-end flaw (like for reload or all the other FIXMEs you'll find). 
I wouldn't expect that anyone would fix CCmode shortcomings if some of 
these targets had trouble with it.  And IIUC one of the posts from 
above, m32c is considered to be kicked out because of reload bugs.

- No improvements of generated code are expected.  avr won't benefit 
from separating comparisons from branches (no scheduling).

- Likewise for insn splitting:  If the avr port could benefit more from 
splitting, then such splitting would have to be performed before 
register allocation -- which is not supported as LRA is restricted to 
cases that don't clobber CC (which is not possible for avr), and reload 
will also die soon IIUC.  Hence any CCmode implementation for avr will 
jump in after RA, even if reload might still be in use.

- Currently the best instruction sequence is printed during asm out. 
Often, there is a multitude of different sequences that could perform 
the same task, and the best (usually w.r.t. length) is chosen ad doc. 
The cc0 setting and insn length computation follows the sequence, i.e. 
there are implicit assertions between printed code, insn lengths and cc0 
effect.  All this is in a single place, cf. avr_out_plus all its callees 
like avr_out_plus_1.  Usually, it is not possible to describe the 
conditions for specific sequences on RTL or constraint level (would need 
to filter depending on cartesian product over all constraints, and this 
is not possible because not allowed in insn conditions).

Switching to CCmode would basically require to throw avr into the dust 
bin and start the backend from scratch, at least considerable parts of c 
and md. Even if switching to a clobbers-all solution is feasible, this 
will result in performance drop, and fixing that will likely be no easy 
task (if possible with a reasonable effort at all) and greatly 
destabilize the backend.

Actually, LLVM has an evolving avr backend.  It's far from being mature 
and less stable and optimizing than gcc's.  But instead of putting work 
into a dead horse (at least re. avr) like gcc with strong tendencies of 
self-destruction (which removing cc0 is, IMO), it seems much more 
reasonable to switch to an infrastructure that's more friendly to such 
architectures and not in the decline.

In my option, one of the great upsides of GCC is that it supports so 
many targets, many deeply embedded, mature targets amongst them.  With 
that background, it may very well make sense to have considerably 
different approaches to the same problem.  And most of cc0 code is in 
final and a few parts that keep comparisons and branches together.  So 
kicking out cc0 doesn't seem to bring a maintenance boost, either...

Johann