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!)
