Question about indirect functions and PGO

Question about indirect functions and PGO

[Erick Ochoa]

Hello,

I'm working on an optimization and I encountered this interesting 
behaviour. There are a couple of functions that are specialized when the 
program is not compiled with PGO (-fprofile-generate and -fprofile-use)

However, when the program is compiled with PGO the compiler does not 
specialize the function calls.

I printing the program just after materializing all clones.

I am running this version of GCC:
Author: GCC Administrator <gccadmin@gcc.gnu.org>
Date:   Fri Jul 10 00:16:28 2020 +0000

     Daily bump.

I can imagine that the profiling information was used to determine that 
specializing these functions is a bad tradeoff between binary size and 
speed. But I do not know this for sure. How can I find out why these 
functions were not specialized? (I.e. is there a threshold that wasn't 
met, and if so, where is it located and what's its value?)

Thanks!

Re: Question about indirect functions and PGO

[Erick Ochoa]

Forgot to mention that these functions take a function pointer as a 
parameter and as a result, the specialized functions are able to replace 
the indirect function call with a direct function call.

On 10/07/2020 13:17, Erick Ochoa wrote:
> Hello,
> 
> I'm working on an optimization and I encountered this interesting 
> behaviour. There are a couple of functions that are specialized when the 
> program is not compiled with PGO (-fprofile-generate and -fprofile-use)
> 
> However, when the program is compiled with PGO the compiler does not 
> specialize the function calls.
> 
> I printing the program just after materializing all clones.
> 
> I am running this version of GCC:
> Author: GCC Administrator <gccadmin@gcc.gnu.org>
> Date:   Fri Jul 10 00:16:28 2020 +0000
> 
>      Daily bump.
> 
> I can imagine that the profiling information was used to determine that 
> specializing these functions is a bad tradeoff between binary size and 
> speed. But I do not know this for sure. How can I find out why these 
> functions were not specialized? (I.e. is there a threshold that wasn't 
> met, and if so, where is it located and what's its value?)
> 
> Thanks!

Re: Question about indirect functions and PGO

[Erick Ochoa]

Hi,

I just wanted to answer myself.
It seems that there are two thresholds that need to be met if a function 
is to be specialized within a particular context:

1. --param=hot-bb-count-ws-permille=. This option controls the hotness 
threshold of basic blocks and is needed for function specialization 
during LTO. If a callsite is not in a hot basic block, it seems that the 
callsite will not be specialized for a particular parameter.
2. --param=ipa-cp-eval-threshold=. This option controls a heuristic that 
lets constant propagation happen if a function is a good candidate for 
cloning. This parameter is used for both: function specialization within 
a particular context and for all contexts.

On 10/07/2020 13:19, Erick Ochoa wrote:
> Forgot to mention that these functions take a function pointer as a 
> parameter and as a result, the specialized functions are able to replace 
> the indirect function call with a direct function call.
> 
> On 10/07/2020 13:17, Erick Ochoa wrote:
>> Hello,
>>
>> I'm working on an optimization and I encountered this interesting 
>> behaviour. There are a couple of functions that are specialized when 
>> the program is not compiled with PGO (-fprofile-generate and 
>> -fprofile-use)
>>
>> However, when the program is compiled with PGO the compiler does not 
>> specialize the function calls.
>>
>> I printing the program just after materializing all clones.
>>
>> I am running this version of GCC:
>> Author: GCC Administrator <gccadmin@gcc.gnu.org>
>> Date:   Fri Jul 10 00:16:28 2020 +0000
>>
>>      Daily bump.
>>
>> I can imagine that the profiling information was used to determine 
>> that specializing these functions is a bad tradeoff between binary 
>> size and speed. But I do not know this for sure. How can I find out 
>> why these functions were not specialized? (I.e. is there a threshold 
>> that wasn't met, and if so, where is it located and what's its value?)
>>
>> Thanks!

Re: Question about indirect functions and PGO

[Victor Rodriguez]

On Mon, Jul 13, 2020 at 6:41 AM Erick Ochoa
<erick.ochoa@theobroma-systems.com> wrote:
>
> Hi,
>
> I just wanted to answer myself.
> It seems that there are two thresholds that need to be met if a function
> is to be specialized within a particular context:
>
> 1. --param=hot-bb-count-ws-permille=. This option controls the hotness
> threshold of basic blocks and is needed for function specialization
> during LTO. If a callsite is not in a hot basic block, it seems that the
> callsite will not be specialized for a particular parameter.
> 2. --param=ipa-cp-eval-threshold=. This option controls a heuristic that
> lets constant propagation happen if a function is a good candidate for
> cloning. This parameter is used for both: function specialization within
> a particular context and for all contexts.
>
> On 10/07/2020 13:19, Erick Ochoa wrote:
> > Forgot to mention that these functions take a function pointer as a
> > parameter and as a result, the specialized functions are able to replace
> > the indirect function call with a direct function call.
> >
> > On 10/07/2020 13:17, Erick Ochoa wrote:
> >> Hello,
> >>
> >> I'm working on an optimization and I encountered this interesting
> >> behaviour. There are a couple of functions that are specialized when
> >> the program is not compiled with PGO (-fprofile-generate and
> >> -fprofile-use)
> >>
> >> However, when the program is compiled with PGO the compiler does not
> >> specialize the function calls.
> >>
> >> I printing the program just after materializing all clones.
> >>
> >> I am running this version of GCC:
> >> Author: GCC Administrator <gccadmin@gcc.gnu.org>
> >> Date:   Fri Jul 10 00:16:28 2020 +0000
> >>
> >>      Daily bump.
> >>
> >> I can imagine that the profiling information was used to determine
> >> that specializing these functions is a bad tradeoff between binary
> >> size and speed. But I do not know this for sure. How can I find out
> >> why these functions were not specialized? (I.e. is there a threshold
> >> that wasn't met, and if so, where is it located and what's its value?)
> >>

Have you tried the new option-fprofile-partial-training ?

-fprofile-partial-training can now be used to inform the compiler that
code paths not covered by the training run should not be optimized for
size.

I tested by myself this week and it literally do not optimize at all
the functions not touched by the training

Regards

Victor Rodriguez

> >> Thanks!