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
