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 968173858414 for ; Wed, 10 May 2023 13:15:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 968173858414 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 11D7F28502B; Wed, 10 May 2023 15:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1683724543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YzVEgU8qOXq3/Svqj7NPYT1rn4oec4eByWelTCPhjHA=; b=PIdzbrb6O7vxrufolp73thB+yPLO78m55XV48r4ZBWzZ/8Cuc1Mv1K1Le/MQK89HCohmmz qLCoDfm7WIXwMSpJe+6bP2vWXVPciuO1ZPS7Rf6FxpR9DnelXrDv5EpPzMiPOPBcrNr/0t Ij8Mg43k22Lqhwn/tW04FuhzYa+S/II= Date: Wed, 10 May 2023 15:15:43 +0200 From: Jan Hubicka To: Qing Zhao Cc: Martin =?iso-8859-2?Q?Li=B9ka?= , gcc Patches , Martin Jambor Subject: Re: Question on patch -fprofile-partial-training Message-ID: References: <2A707DB2-5BCE-4F1F-A971-67AC55B30297@oracle.com> <5FEEC8EF-85A8-4A94-ABE0-3E783F0C8A7C@oracle.com> <83fbeb1d-9bf8-1434-d8cb-a9827b1af266@suse.cz> <30e4827a-1a4d-1a26-6158-5e7c967e5268@suse.cz> 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Honza, > > Main motivation for this was profiling programs that contain specific > > code paths for different CPUs (such as graphics library in Firefox or Linux > > kernel). In the situation training machine differs from the machine > > program is run later, we end up optimizing for size all code paths > > except ones taken by the specific CPU. This patch essentially tells gcc > > to consider every non-trained function as built without profile > > feedback. > Make sense. > > > > For Firefox it had important impact on graphics rendering tests back > > then since the building machined had AVX while the benchmarking did not. > > Some benchmarks improved several times which is not a surprise if you > > consider tight graphics rendering loop optimized for size versus > > vectorized one. > > That’s a lot of improvement. So, without -fprofile-partial-training, the PGO hurt the performance for those cases? Yes, to get code size improvements we assume that the non-trained part of code is cold and with -Os we are very aggressive to optimize for size. We now have two-level optimize_for size, so I think we could make this more fine grained this stage1. Honza > > > The patch has bad effect on code size which in turn > > impacts performance too, so I think it makes sense to use > > -fprofile-partial-training with bit of care (i.e. only one code where > > such scenarios are likely). > > Right. > > > > As for backporting, I do not have checkout of GCC 8 right now. It > > depends on profile infrastructure that was added in 2017 (so stage1 of > > GCC 8), so the patch may backport quite easilly. I am not 100% sure > > what shape the infrastrucure was in the first version, but I am quite > > convinced it had the necessary bits - it was able to make the difference > > between 0 profile count and missing profile feedback. > > This is good to know, I will try to back port to GCC8 and let them test to see any good impact. > > Qing > > > > Honza > >> >