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;
next prev parent 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).