On Fri, May 22, 2020 at 01:22:10PM +0200, Richard Biener wrote: > On Wed, May 20, 2020 at 10:37 PM Segher Boessenkool > <seg...@kernel.crashing.org> wrote: > > > > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote: > > > I think this is the wrong way to approach this. You're doing too many > > > things at once. Try to fix the powerpc regression with the extra > > > flag_rtl_unroll_loops, that could be backported. Then you can > > > independently see whether enabling more unrolling at -O2 makes > > > sense. Because currently we _do_ unroll at -O2 when it does > > > not increase size. Its just your patches make this as aggressive > > > as -O3. > > > > Just do a separate flag (and option) for cunroll, instead? > > > > The RTL unroller is *the* unroller, and has been since forever. > > Sorry but that ship has sailed - I don't think we should make > -O2 -funroll-loops no longer affect GIMPLE.
Of course, and it would certainly be good if we could do some non- trivial unrolling earlier. My point is, why rename all RTL stuff now? That is just churn. (And we will need to keep unrolling in RTL for a long time still, if not forever). > But sure, what I am proposing is have > > -frtl-unroll-loops > -fgimple-unroll-loops > > with obvious semantics and -funroll-loops enabling both. > Users should not really care about what is RTL or GIMPLE. Yeah -- so this shouldn't be part of the name at all. What you care about are higher level characteristics of the unrolling, like "complete" or "early" or whatever. > The split above allows the "bug" to be fixed (even on the branch) > without introducing even more target specialities. So does any split. Or I don't see what you mean? Segher
