[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