From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15516 invoked by alias); 26 Oct 2004 18:57:23 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15389 invoked from network); 26 Oct 2004 18:57:19 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 26 Oct 2004 18:57:19 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i9QJ2K0N003837 for ; Tue, 26 Oct 2004 12:02:20 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Tue, 26 Oct 2004 11:57:23 -0700 Received: from [17.201.20.87] (mrs2.apple.com [17.201.20.87]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i9QIvGe6018457; Tue, 26 Oct 2004 11:57:16 -0700 (PDT) In-Reply-To: <20041023124015.GA4154@cs.kuleuven.ac.be> References: <20041020123432.GA31922@cs.kuleuven.ac.be> <7190B68C-2302-11D9-82D0-000D9330C092@apple.com> <20041023124015.GA4154@cs.kuleuven.ac.be> Mime-Version: 1.0 (Apple Message framework v677) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: 7bit From: Mike Stump Subject: Re: Slowdowns in code generated by GCC>=3.3 Date: Tue, 26 Oct 2004 20:26:00 -0000 To: Remko Troncon X-SW-Source: 2004-10/txt/msg01039.txt.bz2 On Oct 23, 2004, at 5:40 AM, Remko Troncon wrote: >> Another thought, you can binary search the compiler sources from cvs, >> compiling your application at each instance to determine the patch >> that >> went in that regressed performance for you. > > I did a search through GCC CVS to find out which patch caused our > factor > 3 slowdown. Apparently, it is the patch with this ChangeLog entry: > > 2003-02-15 Richard Henderson > * bb-reorder.c (find_traces_1_round): Don't connect easy to > copy > successors with multiple predecessors. > (connect_traces): Try harder to copy traces of length 1. > * function.h (struct function): Add computed_goto_common_label, > computed_goto_common_reg. > * function.c (free_after_compilation): Zap them. > * stmt.c (expand_computed_goto): Use them to produce one > indirect branch per function. Wait, we're not done yet, that is just the first step. The next step is to find an instance of changed code generation... It would help if you gperf or gcov your code, and then find a hot instance of the code that changed. gcc -save-temps can be used to preserve the preprocessed source code and the assembly. From there, if you can, trim down the extraneous code from the .i/.ii file and then submit that file as a bug report, with the flags, then generated .s before and after, and the net effect of the change (3x application slowdown) and the fact it is a regression and a pointer to the above changelog entry and the timings you get with and without that.