From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28121 invoked by alias); 12 Apr 2011 15:09:08 -0000 Received: (qmail 28107 invoked by uid 22791); 12 Apr 2011 15:09:07 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 15:09:03 +0000 Received: (qmail 17138 invoked from network); 12 Apr 2011 15:09:02 -0000 Received: from unknown (HELO localhost) (froydnj@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Apr 2011 15:09:02 -0000 Date: Tue, 12 Apr 2011 15:09:00 -0000 From: Nathan Froyd To: Richard Guenther Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] add statistics counting to postreload, copy-rename, and math-opts Message-ID: <20110412150901.GI23480@codesourcery.com> References: <20110412141626.GF23480@codesourcery.com> <20110412143205.GG23480@codesourcery.com> <20110412145143.GH23480@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00901.txt.bz2 On Tue, Apr 12, 2011 at 04:54:43PM +0200, Richard Guenther wrote: > On Tue, Apr 12, 2011 at 4:51 PM, Nathan Froyd wrote: > > True, but maybe those testcases should be adjusted--per-pass flags, > > rather than blindly assuming -O2 includes them.  And it's not clear to > > It's easier to add things to GCC than to argue removing things ... And sometimes not even easy to argue for adding things. :) > > me that the statistics_counter_event infrastructure really helps > > catching do-nothing passes, since it doesn't record stats that increment > > by zero... > > Well, if the overall count is zero then nothing was done. Granted, but that fact should still be recorded. The situation we have today, for something like: func1: statistic for "statx" was 0 - nothing is recorded in the statistics table func2: statistic for "statx" was 0 - nothing is recorded in the statistics table func3: statistic for "statx" was 0 - nothing is recorded in the statistics table ... and so forth, is that at the end of the day, the dump file won't even include any information about "statx". If you had some func7387 where "statx" was non-zero, you could infer that nothing else happened in the previous 7386 functions. For the case where a pass is truly useless on a TU, it's hard to figure out from the statistics dump alone. And I'd argue that it's useful to see explicitly that the pass only helped in 1 out of 7387 functions, rather than trying to infer it from missing data. -Nathan