[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

guojiufu at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed May 13 02:59:30 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018

--- Comment #26 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #20)
> (In reply to Jiu Fu Guo from comment #18)
> > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > if the loop has multi-exits or upbound is not a fixed number, we may not do
> > 'complete unroll' for the loop, except -funroll-all-loops is specified.
> 
> That doens't make much sense (-funroll-all-loops is RTL unroller only).

-funroll-all-loops is used by RTL unroller (decide_unroll_stupid for loop like 
"while (cond) body"). 
And during option handling, -funroll-all-loops also enables -funroll-loops.
When I thinking about for "cunroll", we may also use a flag to control those
loops to be unrolled less, this option come into my mind.

> 
> I think the growth limits are simply too large unless we compute a "win"
> which we in this case do not.  So I'd say the growth limits should scale
> with win ^ (1/new param) thus if we estimate to eliminate 20% of the
> loop stmts due to unrolling then the limit to apply is
> limit * (0.2 ^ (1/X)) with X maybe defaulting to 2.

It the growth limit seems could be refined. The ^ is an exponent operation,
right?

> 
> I'd only apply this new limit for peeling (peeling is when the loop count
> is not constant and thus we keep the exit tests).
> 
> Of course people want more peeling (hello POWER people!)


More information about the Gcc-bugs mailing list