From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 60D44393BC3D for ; Fri, 23 Apr 2021 16:41:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 60D44393BC3D Received: by mail-pg1-x533.google.com with SMTP id q10so35558437pgj.2 for ; Fri, 23 Apr 2021 09:41:41 -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=h/sQKz1jQUHsoMe2nFZlPGTTRYCb/4n4aflUouNY+Io=; b=RdlQznh3HImrStMejZo+YJ8FZE3cmnG8s0zK71jgZmsNVYzQ0KOScpEnqd/i4+n9h0 u9slZSchVeqwIq/9HkZxTOQciKgtW+QdJ2g7Or1xxUTFJi8BZKTiVXxgiuP31ie+pjLU KdvlxNvtDJB+zjHK05mqxQxyEDzOMJvgvRhNYq6lnzB9iU7N/8jw6pA2h8o6hxVB4Whq /Rnfarhg590HUBgL4g0tFIiVCP9qQdCvnk/x9ITJZVWT9NSwi1Vjm+8q8eIQUx8ngi5/ 0gdGT14v9yC35ml3+i+nL2Ysf2TUIVvJblb2pgicSO2prVyhTqHwaSL20DFNMNyNqCbw VQgw== X-Gm-Message-State: AOAM530GhcNFLokbu5MMlQNBJZuvllL1Yhwsw39nP3PGBEx5XPuzEzIJ 1JDroAhfQbXA4ORapWPtANAZWzouXXvQQZ837ljDUQ== X-Google-Smtp-Source: ABdhPJxw/APPxMpy1puuwu5x3WFaoXr9L70JiHPzrugj2aTuZhG0uR3Y8fJTgEMLgyra9eNoqVwNYRP9nwopVSEJMBg= X-Received: by 2002:a65:584e:: with SMTP id s14mr4528803pgr.229.1619196100261; Fri, 23 Apr 2021 09:41:40 -0700 (PDT) MIME-Version: 1.0 References: <62330f82-201d-af7d-d1ed-1c8c529cc0f7@suse.cz> <20210422222906.GB5803@kam.mff.cuni.cz> In-Reply-To: From: Xinliang David Li Date: Fri, 23 Apr 2021 09:41:30 -0700 Message-ID: Subject: Re: State of AutoFDO in GCC To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Richard Biener , "gcc@gcc.gnu.org" , Jan Hubicka , Eugene Rozenfeld X-Spam-Status: No, score=-16.8 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" Content-Transfer-Encoding: quoted-printable 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 16:41:43 -0000 On Fri, Apr 23, 2021 at 12:18 AM Martin Li=C5=A1ka wrote: > On 4/23/21 9:00 AM, Richard Biener via Gcc wrote: > > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc > > wrote: > >> > >> 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. > > Hi. > > The current situation is that AutoFDO doesn't work with pretty simple > test-cases > we have in testsuite: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71672 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D81379 > > These are ~5 years old and nothing has happened. > > I'm pretty sure the current autofdo can't emit a .gcda file format that > I've changed in the recent years. > I have not not looked into the details, but is it possible the problem is at GCC side (e.g, debug info quality etc)? > > > > > I think if we want to keep the feature it makes sense to provide > create_gcov > > functionality either directly from perf (input data producer) or from g= cc > > (data consumer). Of course I have no idea about its complexity, licens= e > > or implementation language ... > > For me, it's just an i386 feature (maybe aarch64 has perf counters too?), > supported > only by vendor (Intel) and I'm not planning working on that. > I don't like having a feature that is obviously broken and potential GCC > users get > bad experience every time they try to use it. > It must be working at sometime, so perhaps a bisect of GCC revisions can reveal when it regressed. > Can we at least deprecate the feature for GCC 11? If these is enough > interest, > we can fix it, if not, I would remove it in GCC 13 timeframe. > This is a major feature in Clang. Deprecating it in GCC will be unfortunate= . David > > Thoughts? > Martin > > > > > Having the tool third-party makes keeping the whole chain working more > > difficult. > > > > Richard. > > > >> 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 fro= m > >>> 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 alwa= ys > >>> found potentially interesting. > >>> > >>> Honza > >>>> > >>>> Martin > >>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Eugene > >>>>> > >>>> > >>> > >