https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #23 from davidxl <xinliangli at gmail dot com> ---
(In reply to Jan Hubicka from comment #22)
> > > Doing it at same approximately the same place as loop header copying
> > > seems to
> > > make most sense to me. It benefits from early cleanups and DCE definitly
> > > and
> > > it should enable more fun with the later scalar passes that are almost all
> > > rerun then.
> >
> > We need to make sure tracer doesn't mess too much with loops then.
> > Btw, "useless" tracing may be undone again by tail-merging.
>
> Tracer already does:
>
> /* We have the tendency to duplicate the loop header
> of all do { } while loops. Do not do that - it is
> not profitable and it might create a loop with multiple
> entries or at least rotate the loop. */
> && bb2->loop_father->header != bb2)
>
> so it won't kill natural loops and peel (I should find time to update the
> peeling pass). It also has:
>
> if (bb_seen_p (bb2) || (e->flags & (EDGE_DFS_BACK | EDGE_COMPLEX))
> || find_best_successor (bb2) != e)
> break;
>
> to not unroll. So i think it is safe for loop optimizer - all it can do
> is expanding a loop that has control flow in it reducing its unrollability
> later.
> >
> > Tracer seems to consume only profile information and thus doesn't
> > rely on any other transforms (well, apart from cleanups which could
> > affect its cost function). Why not schedule it even earlier?
> > Like to before pass_build_alias? (the pipeline up to loop transforms
> > is quite a mess...)
>
> It uses profile information and code size estiamtes. I expect that
> (especially
> for C++ stuff) the early post inline passes will remove a lot of code and
> thus
> improve traceability. This is why I looked for spot after first DCE/DSE.
>
> David, can you please be more specific about how you tested? Was it with
> profile feedback? What about code size metrics?
It is with profile feedback. There is also reduction in code size, though very
tiny change.
David
>
> Honza
