From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9491 invoked by alias); 13 Apr 2011 18:43:14 -0000 Received: (qmail 9482 invoked by uid 22791); 13 Apr 2011 18:43:14 -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; Wed, 13 Apr 2011 18:43:09 +0000 Received: (qmail 1242 invoked from network); 13 Apr 2011 18:43:09 -0000 Received: from unknown (HELO localhost) (froydnj@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Apr 2011 18:43:09 -0000 Date: Wed, 13 Apr 2011 18:43: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: <20110413184308.GW23480@codesourcery.com> References: <20110412141626.GF23480@codesourcery.com> <20110412143205.GG23480@codesourcery.com> <20110412145143.GH23480@codesourcery.com> <20110412150901.GI23480@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/msg01023.txt.bz2 On Wed, Apr 13, 2011 at 11:07:15AM +0200, Richard Guenther wrote: > On Tue, Apr 12, 2011 at 5:09 PM, Nathan Froyd wrote: > > 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. > > I always use statistics-stats (thus, overall stats, not per function). The > per function ones omit zero counts during dumping on purpose > (to make the dump smaller). I didn't know about statistics-stats (or didn't realize that's what the code was trying to do), that's useful. And it looks like all the statistics dumping things omit zero counts on purpose, not just the per-function ones. But that has no bearing on the point above: zero counts are not even *recorded* today. E.g. if you apply the patch upthread, grab a random C file, compile it with -O2/3 -fdump-statistics/-stats, and examine the dump file, you might not even know that new statistics counters have been added. Taking out the checks to avoid printing zero counts doesn't help either, because the data simply doesn't get recorded. This infrastructure makes it somewhat difficult to figure out, in an automated way from the dump file alone, whether passes are actually doing anything. Enough grousing. I'm assuming turning on accumulation and dumping of zero counts always would be frowned upon; would it be acceptable to turn accumulation and dumping of zero counts if -details is given? -Nathan