From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26534 invoked by alias); 29 Sep 2014 19:30:36 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26461 invoked by uid 48); 29 Sep 2014 19:30:30 -0000 From: "xinliangli at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/35545] tracer pass is run too late Date: Mon, 29 Sep 2014 19:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.4.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: xinliangli at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg02716.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 --- Comment #23 from davidxl --- (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