[PATCH 1/2] rs6000: tune cunroll for simple loops at O2

[Segher Boessenkool]

On Fri, May 22, 2020 at 01:22:10PM +0200, Richard Biener wrote:
> On Wed, May 20, 2020 at 10:37 PM Segher Boessenkool
> <segher@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?


Segher