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. Richard. > >Segher
