Hi Robin, On Thu, Aug 29, 2019 at 11:08:11AM +0200, Robin Dapp wrote: > >> PR37451. Not clear what target that regressed on, btw. > > > > And PR55190 and PR67288 and probably more. > > Thanks for finding those. So the hope is to get this fixed or rather > move towards a fix with the patch series that's currently reviewed which > injects some doloop knowledge into ivopts?
The long-term plan is to do more and more of the loop optimisation earlier, at Gimple level, and to certainly do almost no analysis on the RTL, as done currently. But this is a longer term still somewhat vague plan. Right now ivopts decides if a loop can use doloop, and costs stuff based on that. Next steps will be to communicate "please use / do not use doloop here" down to RTL. Perhaps the doloop expansion should move closer to the expand pass as well. And it's not just doloop -- the unrolling should be done earlier, too. How much of this will ever work out, and how much of it will make GCC 10, hrm I need a new crystal ball :-) > As said before, I was thinking of storing niter + 1 somewhere and use > this instead of doing the + 1 later when it cannot be simplified > anymore. But if we expect a larger rewrite anyway, it's probably not > worthwhile to pursue that now. This sounds like a pretty simple short-term solution. If it works, I'm all for it :-) Segher
