On Thu, Dec 5, 2019 at 1:41 PM Martin Liška <mli...@suse.cz> wrote:
>
> On 12/5/19 1:30 PM, Richard Biener wrote:
> > I wonder if the behavior shouldn't be the default? The only thing we lose
> > is failing to notice really cold calls (error paths) in programs?
>
> I would also consider enabling that by default.
So I'd add the "reverse" option -fconsider-unprofiled-functions-cold or
so. Your proposed change makes functions not executed during profiling
behave as if the function were built without -fprofile-generate for training
but with -fprofile-use later? Documentation should somehow relate
behavior to that.
Richard.
> I'm sending a language correction for the option documentation:
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 26a444ac7b2..130529dece1 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -10637,10 +10637,10 @@ This option is enabled by @option{-fauto-profile}.
> @item -fprofile-partial-training
> @opindex fprofile-use
> With @code{-fprofile-use} all portions of programs not executed during train
> -run are optimized agressively for size rather than speed. In some cases it
> is not
> +run are optimized aggressively for size rather than speed. In some cases it
> is not
> practical to train all possible paths hot paths in the program. (For example
> -program may contain functions specific for a given hardware and trianing may
> -not cover all hardware configurations program is run on.) With
> +a program may contain functions specific for a given hardware and training
> may
> +not cover all hardware configurations program can run on). With
> @code{-fprofile-partial-training} profile feedback will be ignored for all
> functions not executed during the train run leading them to be optimized as
> if they were compiled without profile feedback.
>
> Martin
