From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8258 invoked by alias); 26 Apr 2011 12:17:05 -0000 Received: (qmail 8244 invoked by uid 22791); 26 Apr 2011 12:17:04 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Apr 2011 12:16:47 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/48732] Nested loops with small iteration count gobble time in "tree reassociation" X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 26 Apr 2011 12:17:00 -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 X-SW-Source: 2011-04/txt/msg02609.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48732 --- Comment #2 from Richard Guenther 2011-04-26 12:13:50 UTC --- With -O1 we do not perform expensive control-dependend DCE and thus do not end up removing the empty loops. We do however remove the dead store in the innermost loop which then causes us to compute that completely unrolling all loops is profitable (we basically see it's all dead code that will be produced). Now, unfortunately before removing all that dead code we perform re-association on the induction variable increment chains ... of which there are a lot (8 ^ n ones and more, actually). We've known for quite some time that not doing constant propagation and dead code elimination on the unrolled loop bodies isn't the best idea (induction variable analysis is also pessimized by not doing CSE on those). The only CCP-like pass after loop opts is VRP which does not run at -O2, or DOM and both runs after re-assoc (though I don't see a particularly good reason for that fact). Scheduling DOM right after loop opts "fixes" this. But a more proper fix would be to do cleanups closer to unrolling.