[PATCH 1/2] Introduce flag_cunroll_grow_size for cunroll

[Segher Boessenkool]

On Thu, May 28, 2020 at 12:01:26PM +0200, Richard Biener wrote:
> On Thu, May 28, 2020 at 10:52 AM guojiufu <guojiufu@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