From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5802 invoked by alias); 25 Jan 2012 19:25:33 -0000 Received: (qmail 5790 invoked by uid 22791); 25 Jan 2012 19:25:32 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TX 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; Wed, 25 Jan 2012 19:25:20 +0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/52001] New: [4.7 reegression] Huge compile-time regression with var-tracking Date: Wed, 25 Jan 2012 20:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-01/txt/msg02973.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52001 Bug #: 52001 Summary: [4.7 reegression] Huge compile-time regression with var-tracking Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned@gcc.gnu.org ReportedBy: rsandifo@gcc.gnu.org r182760 significantly increased the compile time of 20001226-1.c -O3 -g on mips64-linux-gnu: time for -O3: real 0m25.656s user 0m25.106s sys 0m0.544s time for -O3 -g before r182760: real 0m28.212s user 0m27.586s sys 0m0.624s time for -O3 -g after r182760, CTRL-Ced after: real 15m11.725s user 15m11.177s sys 0m0.496s The testcase has a lot of identical "load high, add low" sequences. Even though there are only two values here (the high part and the result), we end up with thousands of value rtxs and thousands of distinct "reverse" locations attached to the "load high" value. c.f.: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01051.html