This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop optimizer / unroller
Hello,
> I'm confused about the current state of the loop optimizer(s) and
> unroller(s). Looking at the lno branch I see in passes.c calls to
> rest_of_handle_loop_optimize which calls loop_optimize and suggests
> to handle unrolling by -funroll-loops.
no, with -fold-unroll-loops.
> Passes.c also calls
> rest_of_handle_loop2 which seems to exclusively deal with
> unrolling/peeling. Then of course we have tree-ssa-loop-* in lno
> (which cannot do unrolling/peeling at the moment?).
It can, but does not except for complete unrolling of loops (since
there is hardly any advantage of doing other types of unrolling early).
> Where is this all going? I suppose we're going to drop
> rest_of_handle_loop_optimize together with loop.[ch] and unroll.c (is
> those what is reffered to as old unroller and old loop optimizer?).
Yes, that's the plan.
> There is loop-iv/invariant.c which tells it's RTL based - is this the
> "new" loop optimizer?
Yes.
> Do we agree to remove traces of old loop optimizer / unroller for 3.5?
It is unlikely for mainline; we have some measurements from ppc showing
that the new loop optimizer beats the old one, but I suspect there are
many cases when this is not true.
> At least it looks like we're doing both at the moment with
> -floop-optimize?
Doing both what?
Zdenek