From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93273 invoked by alias); 15 Sep 2016 09:51:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 93259 invoked by uid 89); 15 Sep 2016 09:51:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*UA:Coremail, H*x:Coremail, H*x:Server, H*UA:Server X-HELO: pku.edu.cn Received: from mx9.pku.edu.cn (HELO pku.edu.cn) (162.105.129.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Sep 2016 09:51:05 +0000 Received: by ajax-webmail-mailfront02 (Coremail) ; Thu, 15 Sep 2016 17:50:36 +0800 (GMT+08:00) Date: Thu, 15 Sep 2016 10:08:00 -0000 X-CM-HeaderCharset: UTF-8 From: "Yuan, Pengfei" To: "Richard Biener" Cc: "GCC Patches" , "Jan Hubicka" Subject: Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled In-Reply-To: References: <58f49a76.4c20.15712b20e40.Coremail.ypf@pku.edu.cn> <392727ce.b9c7.1572b385ece.Coremail.ypf@pku.edu.cn> X-SendMailWithSms: false Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 MIME-Version: 1.0 Message-ID: <5796fc24.155b.1572d414d84.Coremail.ypf@pku.edu.cn> X-Coremail-Locale: zh_CN X-CM-TRANSID:8oFpogB3cPTsbtpX9cMdAA--.13191W X-CM-SenderInfo: yrsqiiarrtilo6sn3hxhgxhubq/1tbiAgATD1Py7azeWQACs7 X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= X-SW-Source: 2016-09/txt/msg00921.txt.bz2 > Yes. This means it's easy to experiment with other values than zero. Basically > early inlining is supposed to remove abstraction penalty to > > a) reduce FDO instrumentation overhead > b) get more realistic size estimates for the inliner > > a) was particularly important back in time for tramp3d, reducing > profiling runtime > 1000-fold. b) is generally important. > > PARAM_EARLY_INLINING_INSNS is supposed to be a reasonable value to > get abstraction removed but IIRC we increased it quite a bit to also get more > early optimization (to get more accurate inliner estimates). > > What I am saying is that reducing PARAM_EARLY_INLINING_INSNS makes > sense for FDO but reducing it to zero is probably a bit much. > > Can you do your measurements with values between zero and the current > default of 14 (wow, 14 ... didn't know it's _that_ high currently ;)). > What's the > value that crosses the boundary of diminishing returns regarding to code-size > improvements for you? > > Richard. > I see. This procedure may take some time since profile data can not be reused. Yuan, Pengfei