From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by sourceware.org (Postfix) with ESMTPS id 5F62F385841A for ; Tue, 26 Mar 2024 22:39:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F62F385841A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=linux.intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5F62F385841A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.198.163.18 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711492779; cv=none; b=YNEPl6aLWaNB38mw7Rv22h2kyfXEBHveG8iSvJQbIof4pe81XohCtuS7sco2Gh3gXFvwfSLzq3JFAwo9yIgypIPencpPqu2d1m9R3crgUI7Q3MsXJIMplx5AqvTlC3s//qw2zzLRCJnhTIqq5rYyS5LN7TsH37KIrYJlI7SOEq0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711492779; c=relaxed/simple; bh=4Q4emeYDOVbKv5Y7ejB3ymPindJZR6zrJvQ5rULD8KA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=gZMU9BJzS2nRgxhX5vSBfi3Z4GHlOBzTEdkZ04d6eb7sQEnpl41KO1xVGJ+ULM7l86DyAWkv7VdG6+jBgsklmnqOuV5CzwyqRrCCiOBXGvz5IJ5SxWZ7Uuw4bN2NbeLmD6AcQnWB3UQqvX6HSFUTJgQeTw37yFpW+iTw6tfWUyk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711492776; x=1743028776; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=4Q4emeYDOVbKv5Y7ejB3ymPindJZR6zrJvQ5rULD8KA=; b=JAdrPfThmLJUKIF4b9fW9JLSFketEUDwmyBy23QMsynLsUoeEZPSBKoI hnD8J2bBTBuo2D5l7TjgsgSgfPTb4N6DYLo9witzm60ecM8EqXZkYR0GJ Ce13Ea3LVpmc7dEkqDfNgnCmaRMcS7XBDjYjP7gAobScG7RLGhylMnSeF uPW10GTdT/TSrWFFgW0MXBAPETsRd7kpjc3b+nIz66ImmNLh9A0V6k7CS a6tzAv8PVyJ8tMZ14zBrTxGSUFTXnaWusjLcirx+cxOyDAw1m4W8hmTN+ ejwXumGYtGL1EEHVGNP3xjSR0I1PjoebH2NsPaYZeH2D+Ltivp+QCjDpx w==; X-CSE-ConnectionGUID: aIbxQgPySVSd5mnytyJceA== X-CSE-MsgGUID: 66v3FAgITeeEQLbV8UTmBg== X-IronPort-AV: E=McAfee;i="6600,9927,11025"; a="6400254" X-IronPort-AV: E=Sophos;i="6.07,157,1708416000"; d="scan'208";a="6400254" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2024 15:39:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,157,1708416000"; d="scan'208";a="20750225" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2024 15:39:35 -0700 Date: Tue, 26 Mar 2024 15:39:33 -0700 From: Andi Kleen To: Richard Biener Cc: Eugene Rozenfeld , "gcc@gcc.gnu.org" , Snehasish Kumar , Jan Hubicka Subject: Re: AutoFDO tools for GCC Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Mar 26, 2024 at 08:45:22AM +0100, Richard Biener wrote: > On Mon, Mar 25, 2024 at 9:54 PM Eugene Rozenfeld via Gcc > wrote: > > > > Hello, > > > > I've been the AutoFDO maintainer for the last 1.5 years. I've resurrected autoprofiledbootstrap build and made a number of other fixes/improvements (e.g., discriminator support). > > > > The tools for AutoFDO (create_gcov, etc.) currently live in https://github.com/google/AutoFDO repo and GCC AutoFDO documentation points users to that repo. That repo also has tools for LLVM AutoFDO. > > https://github.com/google/AutoFDO has several submodules: https://github.com/google/autofdo/blob/master/.gitmodules > > > > I got a message from Snehasish (cc'd) that google intends to migrate the tools for LLVM to the LLVM repo and wants to archive https://github.com/google/AutoFDO. That will be a problem for AutoFDO in GCC. The idea to find a different home for GCC AutoFDO tools was discussed before on this alias but this becomes more urgent now. One idea was to build these tools from GCC repo and another was to produce gcov from perf tool directly. Andi (cc'd) had some early unfinished prototype for latter. > > > > Please let me know if you have thoughts on how we should proceed. > > I think it makes sense for GCC specific parts to live in the GCC > repository alongside gcov tools. I do wonder how much common code > there is > between the LLVM and the GCC tooling though and whether it makes sense > to keep it common (and working with both frontends)? The > pragmatic solution would have been to fork the repo on github to a > place not within the google group ... In tree would need convincing Google to assign the copyright. Some of the code has problems however. The main problem is that it always loads everything into memory, so you cannot do longer recording session with larger data files. Even the gcc boot strap is already pushing it on a reasonably memory sized machine. The scheme of only processing one target at a time is also quite inefficient. For systems with shared libraries and multiple binaries it would be much more efficient to do it all in one pass and write multiple gcovs, and then just let Makefiles or gcc wrapper pick. The other big issue is that the perf format keeps adding new records and their perf parser is written in a way that it always asserts on anything it doesn't understand, so there is constant breakage with new perf versions. That is fixable however (I had a patch submitted but it wasn't merged) I think what makes sense to have from the code based are profile_diff/merge etc. which are needed for scalable collection. Or perhaps it would be best if gcov just gained those functionalities. -Andi