On Fri, May 22, 2020 at 6:54 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > 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?
Well, a split that does not affect behavior for non-ppc architectures when the flags by users are unchanged. Because that allows the ppc regression to be fixed on the branch. Then, on trunk, we can think of a better overall flag design. Note that cunroll/cunrolli are not controlled by a flag currently, they are gated on optimize >= [2|3] - it's just that either -funroll-loops or -fpeel-loops causes its heuristics to allow code-size growth by its own metrics according to the unroll --params. So it's a bit difficult to retrofit the heuristic behavior onto new flags unless we want to completely move that over to a --param that may be gets adjusted by -funroll-loops. Richard. > > Segher
