From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2536 invoked by alias); 16 Sep 2016 09:14:32 -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 2524 invoked by uid 89); 16 Sep 2016 09:14:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*Ad:D*edu.cn, H*Ad:D*cn, D*cn, balance X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Sep 2016 09:14:21 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 7E8D054160A; Fri, 16 Sep 2016 11:14:19 +0200 (CEST) Date: Fri, 16 Sep 2016 09:37:00 -0000 From: Jan Hubicka To: Richard Biener Cc: "Yuan, Pengfei" , Jan Hubicka , GCC Patches Subject: Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled Message-ID: <20160916091417.GA29974@kam.mff.cuni.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2016-09/txt/msg01022.txt.bz2 > On Fri, Sep 16, 2016 at 10:50 AM, Yuan, Pengfei wrote: > >> > Here are the results: > >> > > >> > Param Size (GCC5) Time (GCC5) Time (GCC7) > >> > 0 44686265 (-8.26%) 58.772s 66.332s > >> > 1 45692793 (-6.19%) 40.684s 39.220s > >> > 2 45556185 (-6.47%) 35.292s 34.328s > >> > 3 46251049 (-5.05%) 28.820s 27.136s > >> > 4 47028873 (-3.45%) 24.616s 22.200s > >> > 5 47495641 (-2.49%) 20.160s 17.800s > >> > 6 47520153 (-2.44%) 16.444s 15.656s > >> > 14 48708873 5.620s 5.556s > >> > >> Thanks for data! I meant to run the benchmark myself, but had little time to do > >> it over past week becuase of traveling and was also wondering what to do given > >> that spec is rather poor benchmark in this area. Tramp3d is biassed but we are > >> in stage1 and can fine tune latter. I am debugging the libxul crashes in FDO > >> binary now, so we can re-run talos. > > > > It seems to be memory corruption. The content of a pointer becomes 0xe5e5...e5. > > I have tried Firefox 48.0.2, 49b10 and mozilla-central with GCC 6. Same error. > > > >> > Param: value of PARAM_EARLY_INLINING_INSNS > >> > Size: code size (.text) of optimized libxul.so > >> > Time: execution time of instrumented tramp3d (-n 25) > >> > > >> > To balance between size reduction of optimized binary and speed penalty > >> > of instrumented binary, I set param=6 as baseline and compare: > >> > > >> > Param Size score Time score Total > >> > 0 3.39 -3.57 -0.18 > >> > 1 2.54 -2.47 0.07 > >> > 2 2.65 -2.15 0.50 > >> > 3 2.07 -1.75 0.32 > >> > 4 1.41 -1.50 -0.09 > >> > 5 1.02 -1.23 -0.21 > >> > 6 1.00 -1.00 0.00 > >> > 14 0.00 -0.34 -0.34 > >> > > >> > Therefore, I think param=2 is the best choice. > >> > > >> > Is the attached patch OK? > >> > >> Setting param to 2 looks fine > >> > >> > gcc/ChangeLog > >> > * opts.c (finish_options): Adjust PARAM_EARLY_INLINING_INSNS > >> > when FDO is enabled. > >> > > >> > > >> > diff --git a/gcc/opts.c b/gcc/opts.c > >> > index 39c190d..b59c700 100644 > >> > --- a/gcc/opts.c > >> > +++ b/gcc/opts.c > >> > @@ -826,8 +826,14 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set, > >> > maybe_set_param_value (PARAM_STACK_FRAME_GROWTH, 40, > >> > opts->x_param_values, opts_set->x_param_values); > >> > } > >> > > >> > + /* Adjust PARAM_EARLY_INLINING_INSNS when FDO is enabled. */ > >> > + if ((opts->x_profile_arc_flag && !opts->x_flag_test_coverage) > >> > + || (opts->x_flag_branch_probabilities && !opts->x_flag_auto_profile)) > >> > + maybe_set_param_value (PARAM_EARLY_INLINING_INSNS, 2, > >> > + opts->x_param_values, opts_set->x_param_values); > >> > + > >> > >> I would actually preffer to have PARAM_EARLY_ININING_INSNS_FEEDBACK. We > >> already have TRACER_DYNAMIC_COVERAGE_FEEDBACK and other params. The reason is > >> that profile is not a global property of program. It may or may not be > >> available for given function, while params are global. > > > > Whether profile is available for specific functions is not important here because > > profile is loaded after pass_early_inline. Therefore I think setting the param > > globally is fine. > > I also like a new param better as it avoids a new magic constant and > makes playing with > it easier (your patch removes the ability to do statistics like you did via the > early-inlining-insns parameter by forcing it to two). Hmm, you are right that you do not know if this particular function will get profile (forgot about that). Still, please use two params - it is more consistent with what we have now and we may make it profile specific in future.. Honza > > Thanks, > Richard.