https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #31 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> --- (In reply to Richard Biener from comment #28) > > For the loop which has multi-exits, it may not helpful to unroll it, > > especially "complete unroll" may be not helpful. Like loop in in_pack_i4.c. > > Since it would early exit, some iterations(may most iterations) were not > > executed. > > > > Is it a good idea to disable the GIMPLE cunroll for this kind of loop? RTL > > unroll_stupid does not unroll this kind of loop either. > > Well, GIMPLE cunroll specifically handles the situation of peeling such loops > and has a separate --param to control how many extra branches it may > introduce > for those exits. Generally disabling unrolling of such loops isn't a good > idea, > the reason for completely unrolling loops is abstraction removal and not > necessarily producing more optimal loop kernels (the loop is gone > afterwards). I think, the --param, which you said, maybe param_max_peel_branches which default is 31. And currently, param_max_completely_peel_times is default to 16.
