From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 10099385480F for ; Fri, 23 Apr 2021 19:28:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 10099385480F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 89211280DFE; Fri, 23 Apr 2021 21:28:34 +0200 (CEST) Date: Fri, 23 Apr 2021 21:28:34 +0200 From: Jan Hubicka To: Xinliang David Li Cc: "gcc@gcc.gnu.org" , Eugene Rozenfeld Subject: Re: State of AutoFDO in GCC Message-ID: <20210423192834.GA1949@kam.mff.cuni.cz> References: <20210422222906.GB5803@kam.mff.cuni.cz> <20210423165449.GC56452@kam.mff.cuni.cz> <20210423171611.GA82007@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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 19:28:38 -0000 > On Fri, Apr 23, 2021 at 10:27 AM Xinliang David Li > wrote: > > > > > > > On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote: > > > >> > > >> > It uses create_llvm_prof tool which is in the same git repo. The data > >> > parsing part is shared with create_gcov, but the writer is obviously > >> > different for the two tools. > >> > >> OK and what are the main differences between llvmand gcc format? > >> > >> GCC expects GCOV format, I think while LLVM uses a newly designed binary > > format. > > > > > Sorry I missed your next reply. I forgot about the details of GCC' format. Thanks for explanation. How hard would be to make GCC consume this format? Is is reasonably stable and documented somewhere? Does LLVM's auto-FDO support non-Intel CPUs these days? Honza > > David > > > > > >> Honza > >> > > >> > David > >> > > >> > > >> > > Honza > >> > > > > >> > > > 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 > >> > > 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 > >> > > > > >>>>> > >> > > > > >>>> > >> > > > > >>> > >> > > > > > >> > > > > > >> > > > >> > >