From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 678 invoked by alias); 11 Jul 2014 16:44:37 -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 623 invoked by uid 89); 11 Jul 2014 16:44:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f54.google.com Received: from mail-oa0-f54.google.com (HELO mail-oa0-f54.google.com) (209.85.219.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 11 Jul 2014 16:44:28 +0000 Received: by mail-oa0-f54.google.com with SMTP id n16so1465553oag.41 for ; Fri, 11 Jul 2014 09:44:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CJ4gNj0aIuLa12gbelmcGrnevxtv20ria8Ws5egRNZo=; b=gxuZ8FTkcPSWR8/BTjddD81/Yu9Aj1AHq+TxvtASXDowY4/qqbOFj5snpJ8HAmLwNH D8F6HvYcpcPiDZM0Wc0JhULuDUITOEf1Ux/1HyvzUKdks7M5Smitm18ogWfI9PKJfYJy tIsGRSIWkqbexEoKxf38IK1wgMAyAfg1FqqP0tgmfBp6GuJFuwWBgvJoarlMDyHJGK+P bbvABGyt8ifkeUmAEX2Jx3aLiCUxCd6VYU5qmlxIqUNJPDtBuNiq7vsrfEnEQ6xvVtH3 k+2sle31oraehdCTzMk0qGl2j35C5hqQnL7m43W6nSA/WIQZ3aH3HnjcdXGwuGXod0yw RdOw== X-Gm-Message-State: ALoCoQmocoVvIxbuIX90MJnBcxAR701n68cb8w1FHQeDoQ+ivdiClCwcOc9afAedInxgF8hTL/dR MIME-Version: 1.0 X-Received: by 10.182.128.202 with SMTP id nq10mr34860705obb.77.1405097065756; Fri, 11 Jul 2014 09:44:25 -0700 (PDT) Received: by 10.182.44.198 with HTTP; Fri, 11 Jul 2014 09:44:25 -0700 (PDT) In-Reply-To: References: <20140415213850.GA23141@atrey.karlin.mff.cuni.cz> <20140417033448.GC3157@kam.mff.cuni.cz> Date: Fri, 11 Jul 2014 16:44:00 -0000 Message-ID: Subject: Re: [PATCH] offline gcda profile processing tool From: Rong Xu To: Xinliang David Li Cc: Christophe Lyon , Richard Biener , 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/msg00841.txt.bz2 I should use _WIN32 macro. This code is for windows mkdir api. I'll commit a patch for this shortly (approved by honza). -Rong On Fri, Jul 11, 2014 at 8:49 AM, Xinliang David Li wro= te: > What is the macro to test POSIX IO on host? The guard uses > TARGET_POSIX_IO which is not right. > > David > > On Fri, Jul 11, 2014 at 1:12 AM, Christophe Lyon > wrote: >> On 11 July 2014 10:07, Richard Biener wrote: >>> 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. >>> >> >> On my side, commit 212448 breaks the cross-build of GCC for targets >> using newlib: >> * arm-none-eabi >> * aarch64-none-elf >> /usr/include/sys/stat.h: In function <80><98>void >> gcov_output_files(const char*, gcov_info*)<80><99>: >> /usr/include/sys/stat.h:317: error: too few arguments to function >> <80><98>int mkdir(const char*, __mode_t)<80><99> >> /tmp/1392958_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/gcov-tool.c= :96: >> error: at this point in file >> make[2]: *** [gcov-tool.o] Error 1 >> >> Christophe. >> >>>> 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 p= atches. >>>>> >>>>> 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 ma= y 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 function= ality. >>>>>> >>>>>> Sounds good. I assume the autoFDO does not go via gcov tool but rath= er 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 L= IPO >>>>>> 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 cus= tom version >>>>>> that goes via /proc interface (last time I looked). We added some a= bstraction >>>>>> 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 ne= w 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 interface= s. >>>>>> In a longer term, I would like to make FDO profiling intstrumentatio= n to happen >>>>>> at linktime. For that I need to make the instrumentation code (minim= al spaning >>>>>> tree & friends) to work w/o cgraph that would ideally be done in a s= hared >>>>>> 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 han= dle >>>>>>> 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