From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28267 invoked by alias); 17 Apr 2014 03:34:55 -0000 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 Received: (qmail 28254 invoked by uid 89); 17 Apr 2014 03:34:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 17 Apr 2014 03:34:53 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 571C4542FD2; Thu, 17 Apr 2014 05:34:49 +0200 (CEST) Date: Thu, 17 Apr 2014 05:19:00 -0000 From: Jan Hubicka To: Rong Xu Cc: Jan Hubicka , GCC Patches , Xinliang David Li , Teresa Johnson , Dehao Chen Subject: Re: [PATCH] offline gcda profile processing tool Message-ID: <20140417033448.GC3157@kam.mff.cuni.cz> References: <20140415213850.GA23141@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-04/txt/msg00957.txt.bz2 > GCOT_TOOL needs to use this function to read the string in gcda file > to memory to construct gcov_info objects. > As you noticed, gcov runtime does not need this interface. But > gcov-tool links with gcov runtime and it also uses the function. > We could make it available in gcov_runtime, but that will slightly > increase the memory footprint. Yep, it is not really pretty. I wrote bellow some plan how things may be structured in more convenient way. Any work in that direction would be welcome. > > The planned new functions for trunk version is: (1) overlap score b/w > two profiles (2) better dumping (top hot objects/function/counters) > and statistics. > Once this basic version is in, we can start to add the new functionality. Sounds good. I assume the autoFDO does not go via gcov tool but rather uses custom reader of profile data at GCC side? I wonder, are there any recent overview papers/slides/text of design of AutoFDO and other features to be merged? I remember the talk from GCC Summit and I did read some of pre-LTO LIPO sources & papers, but it would be nice to have somethin up to date. > > libgcov-util.o is built in gcc/ directory, rather in libgcc. > It's directly linked to gcov-tool. > So libgcov-util.o is built for HOST, not TARGET. > With makefile changes, we can built HOST version of libgcov-driver.o > and libgcov-merge.o. > I also need to make some static functions/variables public. I suppose that can go with IN_GCOV_TOOL ifdef. So we currently have basic gcov io handling in gcc/gcov-io.c that is borrowed by libgcc/libgcov* code. We also will get libgcov-util.c in libgcc directory that is actually borrowed by by gcc/gcov-tool.c code. We now have one runtime using STDIO for streaming and kernel has custom version that goes via /proc interface (last time I looked). We added some abstraction into libgcov-interface that is the part that relies on STDIO, partly via gcov-io.c code and now we have in-memory handling code in libgcov-util. I guess it would make most sentse to put all the gcov code into a new directory (libgcov) and make it stand-alone library that can be configured 1) for stdio based runtime as we do not 2) for runtime missing the interface and relyin on user providing it 3) for use within gcov file manipulation tools with reorg of GCC/gcov/gcov-dump/gcov-tool to all use the same low-level interfaces. In a longer term, I would like to make FDO profiling intstrumentation to happen at linktime. For that I need to make the instrumentation code (minimal spaning tree & friends) to work w/o cgraph that would ideally be done in a shared implementation > > Won't this get wrong answer when counters[0] is not the same? > > I would expected the merging code to compare the counters first. Similarly for delta counter. > > These *_op functions are for scaling only. So there is only one > profile involved (thus there is no comparison). > The merge handles are in libgcov-merge.c which have the code to handle > mismatched profile targets. I see, OK then. > > > > Adding correct rounding may actually make difference for Martin's startup time work. > > Do you mean to use something like in RDIV macro? Yes. Honza