On Thu, May 28, 2020 at 12:01:26PM +0200, Richard Biener wrote:
> On Thu, May 28, 2020 at 10:52 AM guojiufu <guoji...@linux.ibm.com> wrote:
> > --- a/gcc/common.opt
> > +++ b/gcc/common.opt
> > @@ -2856,6 +2856,10 @@ funroll-all-loops
> > Common Report Var(flag_unroll_all_loops) Optimization
> > Perform loop unrolling for all loops.
> >
> > +funroll-completely-grow-size
> > +Var(flag_cunroll_grow_size) Init(2)
> > +; Control cunroll to allow size growth during complete unrolling
> > +
>
> So this really adds a new compiler option which would need documenting.
The new flag can be marked Undocumented, would that help? It is only
for internal use (which a comment can say as well).
> I fear we'll get into bikeshed territory here as well... I originally thought
> we can use
>
> Variable
> int flag_cunroll_grow_size;
>
> but now realize that does not work well with LTO without adjusting
> the awk scripts to generate option saving/restoring. For your patch
> you'd need to add 'Optimization' to get the flag streamed properly,
> you should also verify the target adjustment done in the backend
> is reflected in LTO mode.
The option machinery together with LTO is too complicated for me :-/
> Now back to the option name ... if we expose the option we should apply
> some forward looking. Currently cunroll cannot be disabled or enabled
> with a flag and the desired new flag simply tunes one knob on it. How
> about adding
>
> -fcomplete-unroll-loops[=may-grow]
>
> to be able to further extend this later
Trying to anticipate how things will be extended later rarely works :-(
> (there's the knob to only unroll
> non-outermost loops and the knob whether to unroll loops where
> intermediate exits are not statically predicted - incompletely controlled
> by -fpeel-loops). There's unfortunately no existing examples that allows
> multiple flags like -fcomlete-unroll-loops=may-grow,outer other than
> the sanitizers which have manual option parsing.
>
> So if there's no good suggestion from option folks maybe go with
>
> -fcomplete-unroll-loops-may-grow
>
> (ick). And on a second thought -fcomplete-unroll-loops[=...] should
> be -funroll-loops[={complete,may-grow,all}] to cover all unrolling
> bases?
>
> I really hate to explode the number of options users have to
> consider optimizing their code ...
Well, the defaults should be good for almost everyone. But after that,
sure, it should be possible to tune things in a reasonable way.
> So if we can defer all this thinking and make a non-option flag
> variable work that would be best IMHO.
:-)
Segher
