On Mon, 23 Nov 2020, Jeff Law wrote: > On 11/23/20 9:49 PM, Hans-Peter Nilsson wrote: > > On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote: > >> This is the primary patch for cc0 removal on the H8 port.? It doesn't > >> have any of the optimization work and many patterns are simply disabled > >> at this time.? It's working well enough to not regress the testsuite. > >> > >> The H8 is similar to the m68k and other ports in that the vast majority > >> of instructions clobber the condition codes, including most of the > >> arithmetic insns that reload needs to use. While there's a special > >> adds/subs that does not modify the condition codes, they only accept > >> constant addends of 1, 2 and 4. With that in mind, this port does not > >> expose cc0 until after reload. So most patterns are defined using > >> define_insn_and_split. The splitter adds the appropriate clobbers. > > JFTR (as I'm repeating a previous note for another port): if > > you'd went for exposing cc0 *before* reload (adding a clobber to > > each pattern that clobbers, then specifying exceptions removing > > them), the amount of (required) define_insn_and_splits would > > have been zero; typically much less churn in the port. That > > approach also has the benefit of insns not "silently" changing > > behavior at reload-time. > > > > You might think a parallel with a clobber for each insn hampers > > some rtl optimizations, but I found that to be not an issue at > > all, doing that for CRIS (at least when comparing to the cc0 > > version). > I've definitely seen cases where exposing the clobber early hurts, so I > went with exposing after reload.
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?) > I also had someone else doing most of the grunt work, my son :-) Given horsework, for sure! brgds, H-P
