This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][LTO/PGO] Warn when both -flto and -fprofile-generate are enabled


> On Wed, Apr 2, 2014 at 2:07 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
> > On Wed, Apr 2, 2014 at 1:50 PM, Markus Trippelsdorf
> > <markus@trippelsdorf.de> wrote:
> >> It is a common mistake to enable both -flto and -fprofile-generate when
> >> building projects. This is not a good idea, because memory use will
> >> skyrocket due to instrumentation. So just warn the user.
> >>
> >> OK for next stage1?
> >
> > I'd rather see if we can fix the underlying issue.  For example as we
> > are now instrumenting as IPA pass we can allocate a single
> > counter array (if the number of global vars is the issue).  Basically
> > split analysis and instrumentation into two phases for that.
> >
> > Or even better, do profile instrumentation as "real" IPA pass.
> 
> Thus, isn't -coverage also facing the same issue?  Thus, is it
> really -fprofile-arcs already or only one of the value profiling pieces?

Yep, -fprofile-arcs will cause similar issues.
Implementing instrumentation as real IPA is on my TODO list, but pretty low,
since it is quite some work; we need to stream CFG into summaries and make
the instrumentation code independent of function bodies, that needs quite some
reorg (at moment we have no way to load cfg alone).

Note that -fprofile-generate -flto gives you a bit more precise profiles than
-fprofile-generate alone, this is because of COMDAT functions from static libraries
that may be lost in the first case.

Honza
> 
> Richard.
> 
> > Richard.
> >
> >> 2014-04-02  Markus Trippelsdorf  <markus@trippelsdorf.de>
> >>
> >>         * common.opt (fprofile-generate): Add flag.
> >>         * opts.c (finish_options): Add new warning.
> >>         (common_handle_option): Set flag.
> >>
> >> diff --git a/gcc/common.opt b/gcc/common.opt
> >> index 62c72f0d2fbf..61e9adfa0df5 100644
> >> --- a/gcc/common.opt
> >> +++ b/gcc/common.opt
> >> @@ -1689,7 +1689,7 @@ Common Report Var(flag_profile_correction)
> >>  Enable correction of flow inconsistent profile data input
> >>
> >>  fprofile-generate
> >> -Common
> >> +Common Var(flag_profile_generate)
> >>  Enable common options for generating profile info for profile feedback directed optimizations
> >>
> >>  fprofile-generate=
> >> diff --git a/gcc/opts.c b/gcc/opts.c
> >> index fdc903f9271a..b62a0d626d94 100644
> >> --- a/gcc/opts.c
> >> +++ b/gcc/opts.c
> >> @@ -833,6 +833,9 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
> >>         error_at (loc, "only one -flto-partition value can be specified");
> >>      }
> >>
> >> +  if (opts->x_flag_generate_lto && opts->x_flag_profile_generate)
> >> +    warning_at (loc, 0, "Enabling both -fprofile-generate and -flto is a bad idea.");
> >> +
> >>    /* We initialize opts->x_flag_split_stack to -1 so that targets can set a
> >>       default value if they choose based on other options.  */
> >>    if (opts->x_flag_split_stack == -1)
> >> @@ -1728,6 +1731,7 @@ common_handle_option (struct gcc_options *opts,
> >>
> >>      case OPT_fprofile_generate_:
> >>        opts->x_profile_data_prefix = xstrdup (arg);
> >> +      opts->x_flag_profile_generate = true;
> >>        value = true;
> >>        /* No break here - do -fprofile-generate processing. */
> >>      case OPT_fprofile_generate:
> >> --
> >> Markus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]