Re: H8 cc0 conversion

[Hans-Peter Nilsson <hp@bitrange.com>]

On Tue, 24 Nov 2020, Eric Botcazou wrote:

> > I'm intested in any notes, however vague, on that matter.  I was
> > a bit surprised to see that myself...that is, after fixing
> > *some* related regressions, like the one in combine.  (Did I
> > actually miss something?)
>
> My recollection for the Visium port would align with what Jeff saw but, on the
> other hand, this could have been very marginal a phenomenon in the end.

Thanks.  Though, without claims substantiated as anything more
than a feeling, I'm going stick out my chin and say that you're
both seasoned enough gcc hackers to be influenced by earlier
experience, and that things have changed enough that this is no
longer true.

Also, early-debug cause-misattribuations may be a factor.  (For
the combine thing, I first suspected it being target rtx_costs.)

Also for visium, it very well be a remaining odd case in
dbr/reorg.  We've only fixed a few paths in that pile, but that
hasn't had any effect in *my* benchmarks.  Hm, I also realize I
can't speak about scheduling and LRA.

With the alternative being the machine description exploding
(linearly) with error-prone edits, I'll insist that for this
kind of machine it's better to expose the target_flags_regnum
clobbers before reload.  So, better try this approach first,
when it costs "nothing", before going for the big(ger) edit of
adding define_insn_and_splits for just-about-everything (bigger
than adding a register clobber to most patterns).

Current cc0 head-count is down to avr, cr16, h8300, vax, with
two of them recently having patches posted, alas not a lot of
ports left to try this advice.

brgds, H-P