[Bug middle-end/35545] tracer pass is run too late

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545

--- Comment #22 from Jan Hubicka <hubicka at ucw dot cz> ---
> > 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?

Honza