From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by sourceware.org (Postfix) with ESMTPS id BA929385BF9C for ; Fri, 23 Apr 2021 04:14:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BA929385BF9C Received: by mail-lf1-x12f.google.com with SMTP id g8so75527196lfv.12 for ; Thu, 22 Apr 2021 21:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z9iQ1NV1noyqhAolNyFhrkczV/ih2yx2GXIImAYG1XE=; b=N8cAHK82f2u0XmrSGdquUM2u5JVNdRTKLBS9etOPc2XhJe88z7UIZKdzK9BtLQLb3i norvDklhZwIqJpcY5k+FW2OSt9fnmU4u3mozjbkI7cp6oCwHHMU7EFiJ354FcYe/h3vb 3jbwtx0aeH02Koqwgoz10FdQNPn3gIlxHn8XLdlxpITCUcbaHCSqTKEGF2yLwALCLDDm Ev3hXzj1CbmDO4GkrZZMqOE1dHmhfleOe73gL7gV0lI1v517MKVNFHgMDt/tlvnNqtiv mc/40idkNeLyD6UIgiKcdkffktc/CmxfJBGEPGRVDLkqJMXCkcGlTgEWmV1Rfaw2xLAo ZFsg== X-Gm-Message-State: AOAM531+bn9h96Ko3nROcQfWIJGpw0ycLIMtSs5TsVoJPBP5nEzpwRCX KDb+teCrU960Ogfs7StS6mZAsPv60SJsLSXsX4q9Hg== X-Google-Smtp-Source: ABdhPJxcppSVkOB65FbwGfG68CkxkluGPPG4oNR0X3K9Rce2Vn2LDPv9h4SvG3QC3smM4yUlxWLENsc3udcwQWlpjNE= X-Received: by 2002:a05:6512:b14:: with SMTP id w20mr1253563lfu.528.1619151259903; Thu, 22 Apr 2021 21:14:19 -0700 (PDT) MIME-Version: 1.0 References: <62330f82-201d-af7d-d1ed-1c8c529cc0f7@suse.cz> <20210422222906.GB5803@kam.mff.cuni.cz> In-Reply-To: <20210422222906.GB5803@kam.mff.cuni.cz> From: Xinliang David Li Date: Thu, 22 Apr 2021 21:14:08 -0700 Message-ID: Subject: Re: State of AutoFDO in GCC To: Jan Hubicka Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , "gcc@gcc.gnu.org" , Eugene Rozenfeld X-Spam-Status: No, score=-17.4 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 04:14:23 -0000 Hi, the create_gcov tool was probably removed with the assumption that it was only used with Google GCC branch, but it is actually used with GCC trunk as well. Given that, the tool will be restored in the github repo. It seems to build and work fine with the regression test. The tool may ust work as it is right now, but there is no guarantee it won't break in the future unless someone in the GCC community tries to maintain it. Thanks, David On Thu, Apr 22, 2021 at 3:29 PM Jan Hubicka wrote: > > On 4/22/21 9:58 PM, Eugene Rozenfeld via Gcc wrote: > > > GCC documentation for AutoFDO points to create_gcov tool that converts > perf.data file into gcov format that can be consumed by gcc with > -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, > https://gcc.gnu.org/wiki/AutoFDO/Tutorial). > > > > > > I noticed that the source code for create_gcov has been deleted from > https://github.com/google/autofdo on April 7. I asked about that change > in that repo and got the following reply: > > > > > > https://github.com/google/autofdo/pull/107#issuecomment-819108738 > > > > > > "Actually we didn't use create_gcov and havn't updated create_gcov for > years, and we also didn't have enough tests to guarantee it works (It was > gcc-4.8 when we used and verified create_gcov). If you need it, it is > welcomed to update create_gcov and add it to the respository." > > > > > > Does this mean that AutoFDO is currently dead in gcc? > > > > Hello. > > > > Yes. I know that even basic test cases have been broken for years in the > GCC. > > It's new to me that create_gcov was removed. > > > > I tend to send patch to GCC that will remove AutoFDO from GCC. > > I known Bin spent some time working on AutoFDO, has he came up to > something? > > The GCC side of auto-FDO is not that hard. We have most of > infrastructure in place, but stopping point for me was always difficulty > to get gcov-tool working. If some maintainer steps up, I think I can > fix GCC side. > > I am bit unsure how important feature it is - we have FDO that works > quite well for most users but I know there are some users of the LLVM > implementation and there is potential to tie this with other hardware > events to asist i.e. if conversion (where one wants to know how well CPU > predicts the jump rather than just the jump probability) which I always > found potentially interesting. > > Honza > > > > Martin > > > > > > > > Thanks, > > > > > > Eugene > > > > > >