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 7A7183854814 for ; Sun, 9 May 2021 17:01:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7A7183854814 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 EBFFA2807CF; Sun, 9 May 2021 19:01:21 +0200 (CEST) Date: Sun, 9 May 2021 19:01:21 +0200 From: Jan Hubicka To: Andi Kleen Cc: 172060045@hdu.edu.cn, gcc , Eugene.Rozenfeld@microsoft.com Subject: Re: State of AutoFDO in GCC Message-ID: <20210509170121.GE25641@kam.mff.cuni.cz> References: <87a6plulkz.fsf@linux.intel.com> <20210426180011.GA1401198@tassilo.jf.intel.com> <20210429054025.GB4032392@tassilo.jf.intel.com> <4d005159.55ea.1791e171ab9.Coremail.172060045@hdu.edu.cn> <875z0378j1.fsf@linux.intel.com> <67df7dbb.5eae.1794bba0ca3.Coremail.172060045@hdu.edu.cn> <7c802b11-857e-78eb-c2e8-0a3044817793@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c802b11-857e-78eb-c2e8-0a3044817793@linux.intel.com> 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, 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: Sun, 09 May 2021 17:01:24 -0000 > > > With my tests, AutoFDO could achieve almost half of the effect of > > instrumentation FDO on real applications such as MySQL 8.0.20 . > > Likely this could be improved with some of the missing changes. Apparently > discriminator support is worth quite a bit especially on dense C++ code > bases. Without that, gcc autofdo only works on line numbers, which can be > very limiting if single lines have a lot of basic blocks. > > Sadly discriminator support is currently only on the old Google branch and > not in gcc mainline > > Longer term it would probably be best to replace all this with some custom > specialized binary annotation instead of stretching DWARF beyond its limits. I think it makes sense to pick the AutoFDO to the lists of things that would be nice to fix in GCC12. I guess first we need to solve the issues with the tool producing autofdo gcda files and once that works setup some benchmarking so we know how things compare to FDO and they get tested. If you point me to the discriminator patches I can try to figure out how hard would be to mainline them. I am not too sure about custom annotations though - storing info about regions of code segment is always a pain and it is quite nice that dwarf provides support for that. But I guess we could go step by step. I first need a working setup ;) Honza > > -Andi >