On Fri, Jul 08, 2016 at 01:28:05AM +0930, Alan Modra wrote: > BTW, both pr70098 and pr71763 are triggered by combine, not > loop-doloop as I was thinking earlier. See rtl dumps for the > testcases. I doubt the "optimization" done by combine here is worth > keeping, since loop-doloop.c ought to already handle the benficial > inner loop use of ctr. Elsewhere we typically end up with an insn > that needs splitting back to the original sequence. So we could avoid > creating trouble for ourselves with the following patch.
I agree on the approach; if there are any missed optimisation because of it, it doesn't weigh up to the frequentish pessimisation we have now. One case it will prevent it bdz before a bdnz loop (for a loop count of zero), but we usually do not generate that anyway, and it isn't obvious it is faster anyway (or smaller, even). > diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md > index 7d9c660..b2d1118 100644 > --- a/gcc/config/rs6000/rs6000.md > +++ b/gcc/config/rs6000/rs6000.md > @@ -148,6 +148,7 @@ > UNSPEC_IEEE128_MOVE > UNSPEC_IEEE128_CONVERT > UNSPEC_SIGNBIT > + UNSPEC_DONT_COMBINE > ]) That is a pretty horrible name. Combine can combine such insns just fine; it won't make up the unspec out of thin air though. It seems you want to use this in other cases that should not be invented by combine as well, but that won't work: combine could then morph one of those into another kind. Maybe just UNSPEC_BDZ? UNSPEC_DOLOOP? > -(define_insn "*ctr<mode>_internal5" > +(define_insn "*ctr<mode>_internal3" Please don't rename the patterns, not if you don't make better names. Thanks, this should be a nice improvement, Segher
