public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Yuan, Pengfei" <ypf@pku.edu.cn>
To: "Jan Hubicka" <hubicka@ucw.cz>
Cc: "Richard Biener" <richard.guenther@gmail.com>,
		"GCC Patches" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled
Date: Fri, 16 Sep 2016 09:01:00 -0000	[thread overview]
Message-ID: <355e6f53.95d3.1573230b35b.Coremail.ypf@pku.edu.cn> (raw)
In-Reply-To: <20160916072531.GB69806@kam.mff.cuni.cz>

> > 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.

> Even at compile time profile may be selectively missing for example for
> COMDATs that did not win in the linking process.
> 
> There is also need to update the documentation.
> Thanks for the work!
> Honza

Here is the new patch.

Regards,
Yuan, Pengfei


gcc/ChangeLog
	* doc/invoke.texi (early-inlining-insns): Value is adjusted
	when FDO is enabled.
	* opts.c (finish_options): Adjust PARAM_EARLY_INLINING_INSNS
	when FDO is enabled.


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1ca4dcc..880a28c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10272,9 +10272,11 @@ The default value is 10.
 
 @item early-inlining-insns
 Specify growth that the early inliner can make.  In effect it increases
 the amount of inlining for code having a large abstraction penalty.
-The default value is 14.
+The default value is 14.  When feedback-directed optimizations is enabled (by
+@option{-fprofile-generate} or @option{-fprofile-use}), the value is adjusted
+to 2.
 
 @item max-early-inliner-iterations
 Limit of iterations of the early inliner.  This basically bounds
 the number of nested indirect calls the early inliner can resolve.
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);
+
   if (opts->x_flag_lto)
     {
 #ifdef ENABLE_LTO
       opts->x_flag_generate_lto = 1;

  reply	other threads:[~2016-09-16  8:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-10  6:41 Yuan, Pengfei
2016-09-14 10:35 ` Richard Biener
2016-09-15  3:17   ` Yuan, Pengfei
2016-09-15  8:44     ` Richard Biener
2016-09-15 10:08       ` Yuan, Pengfei
2016-09-16  5:52       ` Yuan, Pengfei
2016-09-16  8:09         ` Jan Hubicka
2016-09-16  9:01           ` Yuan, Pengfei [this message]
2016-09-16  9:21             ` Richard Biener
2016-09-16  9:37               ` Jan Hubicka
2016-09-16 12:00                 ` Yuan, Pengfei
2016-09-16 12:56                   ` Jan Hubicka
2016-09-20  8:53                     ` Yuan, Pengfei
2016-09-20 11:44                     ` Richard Biener
2016-09-20 11:58                       ` Richard Biener
2016-09-20 12:09                         ` Yuan, Pengfei
2016-09-20 12:19                           ` Richard Biener
2016-09-20 13:10                             ` Yuan, Pengfei
2016-09-21 12:44                         ` Yuan, Pengfei
2016-09-26  4:03                   ` Yuan, Pengfei
2016-10-10  2:23                   ` PING: [PATCH] " Yuan, Pengfei
2016-10-10  9:55                     ` Richard Biener
2016-10-10 10:52                       ` Yuan, Pengfei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=355e6f53.95d3.1573230b35b.Coremail.ypf@pku.edu.cn \
    --to=ypf@pku.edu.cn \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).