On Mon, May 25, 2020 at 1:58 PM Richard Biener <richard.guent...@gmail.com> wrote: > > On May 25, 2020 7:40:00 PM GMT+02:00, Segher Boessenkool > <seg...@kernel.crashing.org> wrote: > >On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote: > >> On Mon, May 25, 2020 at 1:10 PM guojiufu <guoji...@linux.ibm.com> > >wrote: > >> Since a new flag is not needed to fix the regression please avoid > >> adding -fcomplete-unroll-loops. > >> > >> For -frtl-unroll-loops you should be able to use > > > >Erm. That *is* a new command-line option (the internal flags I do not > >care about so much: new implementation details are *good*). And a new > >name that is a mistake in my opinion, for many reasons (users do not > >know and should not have to care about "rtl"; the name is not > >descriptive; it is useless churn, it is not the same name as we have > >had for decades now; it is adding a new option for a future where we > >will do most unrolling at gimple level, a future we do not know will > >ever exist, and we do not know what that will look like anyway; it is > >an extra level of indirection (in the name)). > > > >We should not have an -frtl-unroll-loops if we do not have a > >-ftree-unroll-loops (or whatever). > > > >Unrolling early is not a good idea in general (the problems with the > >very trivial complete unrolling case just underline that). But we > >*should* know which code we expect to unroll later, for better costing. > >Adding names like "rtl-unroll-loops" only stands in the way of getting > >a better design here. > > You folks made ppc specific hacks instead of a better design. Those now stand > in the way as well. But sure, simply do not expose the flag to the users, use > Var(flag_rtl_unroll_loops). My other points still stand. > > Feel free to ignore the regression part on the branch and come up with a > great design. But don't expect to backport that then.
I completely agree. This path is digging a deeper and deeper hole. - David