https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> --- > It the growth limit seems could be refined. The ^ is an exponent operation, > right? Yes. The idea is to limit growth more when there is no benefit of unrolling detected by the cost model (which currently simply counts likely eliminated stmts). (In reply to Jiu Fu Guo from comment #27) > (In reply to Jiu Fu Guo from comment #26) > > (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). > > > > 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). One of my TODO items is to work on its costing model to the extent that we run value-numbering on the unrolled body (that's already done) and roll back the unrolling if there wasn't any visible benefit. The difficult cases are like those in SPEC calculix where for full benefit you need to unroll the 5(!) innermost loops and to even see any benefit you need to unroll the 3 innermost loops.
