From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71851 invoked by alias); 20 Sep 2016 12:14:19 -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 71829 invoked by uid 89); 20 Sep 2016 12:14:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1350, HTo:D*edu.cn, budget, HTo:D*cn X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Sep 2016 12:14:08 +0000 Received: by mail-wm0-f42.google.com with SMTP id l132so205715548wmf.0 for ; Tue, 20 Sep 2016 05:14:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pC/pnVZiKq1rlYkZUS9KC1aI0i2QVmxf38q3RMQAdjk=; b=E03KPBglHgIoXlhFpgqSfxKDSwdgb3rjrZBc2t0HKTQbA8wqIhqCQ0qOuPnslRW8AO 66HrXwTqGHmyOkL5ZJWHJUhtQmyPW0Gt4PvUqRx+oVcYNvLm3GIJt4aYyIOqMZNnp22Z v41rk5n8nU1tYh4MR89jEGwx3WU0x/OycdJjKwuc2ObQR+lLnGr9EisdljPVwCc1tls8 izLpcBcba/9IJkvDKoJrzl9t8L1xfNTfF8gIimUFWfpcMEcSKF24pMdtR0JVc5fEKnIH 8lmJeiD4L7rghFch05cX0w4uOpuWRq5QnqYBqo74iRE4jFmNVvgm+Y7mf8qDLwGh0Rlr Ldfw== X-Gm-Message-State: AE9vXwO7UtBrq3g9j3wz1eYnIdMCjtyq6AUOCPSx7dxGTupLM4dPI9BM+PHczW32esjJn5LZEJjdWFQoeJ9IQg== X-Received: by 10.194.88.137 with SMTP id bg9mr27570900wjb.155.1474373645931; Tue, 20 Sep 2016 05:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.129 with HTTP; Tue, 20 Sep 2016 05:14:05 -0700 (PDT) In-Reply-To: <7a4cbe5e.12e62.15747758f57.Coremail.ypf@pku.edu.cn> References: <58f49a76.4c20.15712b20e40.Coremail.ypf@pku.edu.cn> <392727ce.b9c7.1572b385ece.Coremail.ypf@pku.edu.cn> <339617a6.8f06.1573166cbaf.Coremail.ypf@pku.edu.cn> <20160916072531.GB69806@kam.mff.cuni.cz> <355e6f53.95d3.1573230b35b.Coremail.ypf@pku.edu.cn> <20160916091417.GA29974@kam.mff.cuni.cz> <6ad18072.d732.15732c834ea.Coremail.ypf@pku.edu.cn> <20160916120037.GB3781@kam.mff.cuni.cz> <7a4cbe5e.12e62.15747758f57.Coremail.ypf@pku.edu.cn> From: Richard Biener Date: Tue, 20 Sep 2016 12:19:00 -0000 Message-ID: Subject: Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled To: "Yuan, Pengfei" Cc: Jan Hubicka , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01280.txt.bz2 On Tue, Sep 20, 2016 at 1:57 PM, Yuan, Pengfei wrote: >> > Btw, It occurs to me that then win in code-size might be purely due to the >> > smaller base value for the TU size we use to compute the maximum unit >> > growth with ... any idea how to improve it on this side? Say, computing >> > the TU size before early optimization (uh, probably not ...) >> > >> > That said, the inliner always completely fills its budged, that is, increase >> > the unit by max-unit-growth? >> >> What I'm trying to say is that rather than limiting early inlining we should >> maybe decrease inline-unit-growth when FDO is in effect? Because we >> can better control where the inlining goes. If there is over 8% reduction >> in size benchmarking (unpatched) compiler on Firefox with FDO and >> --param inline-unit-growth=12 might show if the results are the same. >> >> Richard. >> >> > Richard. > > AFAIK, param inline-unit-growth only affects pass_ipa_inline. However, the code > size reduction achieved with my patch is from pass_early_inline. Any inlining you don't do at early inlining time will a) decrease the size inline-unit-growth is computed on b) just delays inlining to IPA inlining (with the now more constrained size budget). Richard. > Yuan, Pengfei