From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15959 invoked by alias); 11 Jul 2014 08:07:42 -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 15931 invoked by uid 89); 11 Jul 2014 08:07:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f42.google.com Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 11 Jul 2014 08:07:36 +0000 Received: by mail-wg0-f42.google.com with SMTP id l18so650459wgh.13 for ; Fri, 11 Jul 2014 01:07:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr62668649wjx.8.1405066049234; Fri, 11 Jul 2014 01:07:29 -0700 (PDT) Received: by 10.194.1.137 with HTTP; Fri, 11 Jul 2014 01:07:29 -0700 (PDT) In-Reply-To: References: <20140415213850.GA23141@atrey.karlin.mff.cuni.cz> <20140417033448.GC3157@kam.mff.cuni.cz> Date: Fri, 11 Jul 2014 08:07:00 -0000 Message-ID: Subject: Re: [PATCH] offline gcda profile processing tool From: Richard Biener To: Rong Xu Cc: Jan Hubicka , GCC Patches , Xinliang David Li , Teresa Johnson , Dehao Chen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00758.txt.bz2 On Mon, May 5, 2014 at 7:17 PM, Rong Xu wrote: > Here is the updated patch. The difference with patch set 3 is > (1) use the gcov-counter.def for scaling operation. > (2) fix wrong scaling function for time-profiler. > > passed with bootstrap, profiledboostrap and SPEC2006. One of the patches breaks bootstrap for me: /space/rguenther/src/svn/trunk/gcc/../libgcc/libgcov.h:184: error: ISO C++ forbids zero-size array =E2=80=98ctrs=E2=80=99 make[3]: *** [libgcov-util.o] Error 1 host compiler is gcc 4.3.4 Richard. > Thanks, > > -Rong > > On Thu, May 1, 2014 at 3:37 PM, Rong Xu wrote: >> Hi, Honza, >> >> Please find the new patch in the attachment. This patch integrated >> your earlier suggestions. The noticeable changes are: >> (1) build specialized object for libgcov-driver.c and libgcov-merge.c >> and link into gcov-tool, rather including the source file. >> (2) split some gcov counter definition code to gcov-counter.def to >> avoid code duplication. >> (3) use a macro for gcov_read_counter(), so gcov-tool can use existing >> code in libgcov-merge.c with minimal change. >> >> This patch does not address the suggestion of creating a new directory >> for libgcov. I agree with you that's a much better >> and cleaner structure we should go for. We can do that in follow-up patc= hes. >> >> I tested this patch with boostrap and profiledbootstrap. Other tests >> are on-going. >> >> Thanks, >> >> -Rong >> >> On Wed, Apr 16, 2014 at 8:34 PM, Jan Hubicka wrote: >>>> 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 functionali= ty. >>> >>> 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 bo= rrowed >>> by libgcc/libgcov* code. We also will get libgcov-util.c in libgcc dir= ectory >>> 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 abst= raction >>> into libgcov-interface that is the part that relies on STDIO, partly vi= a 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 d= irectory >>> (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 t= o 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 shar= ed >>> 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. Sim= ilarly 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 st= artup time work. >>>> >>>> Do you mean to use something like in RDIV macro? >>> >>> Yes. >>> >>> Honza