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: [google] Add options to pattern match function name for hotness attributes


Based on Honza's feedback, I think it is bettre to add command line
interface such as this:

-ffunction-attribute-list=<attribute_name>:<function_pattern_list>
or
-ffunction-attribute-filelist=<attribute_name>:<function_pattern_list_filename>

e.g,

-ffunction-attribute-list=code:foo1,foo2,bar_*,blah

It probably needs to be processed as deferred option to allow other
option to be translated into this form -- for instance extracted from
some global profile data.

thanks,

David

On Sat, Jun 2, 2012 at 7:16 AM, Dehao Chen <dehao@google.com> wrote:
> On Sat, Jun 2, 2012 at 9:17 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> > Well, perhaps the feature would be more useful with command line option allowing
>>> > to add an attribute instead of having special case command line options for individual
>>> > cases.
>>>
>>> Hi, Honza, I'm not sure what you mean by "command line option allowing
>>> to add an attribution". But this seems what this patch does: it adds
>>> attributes to functions with specified name patterns.
>>
>> I mean that if we want to go this route, we may want to allow this interface to i.e. add
>> always_inline attrbute or noinline or such. I can imagine this to be useful especially for
>> languages that has no attributes.
>
> This annotation is mainly for static branch prediction. Some functions
> may be very cold, but it may still be good to inline it.
>
>>
>>>
>>> > ?I guess the problem would be also solvable with header included after
>>> > the library adding the attributes to the declarations
>>> >
>>> > typeof (printf) printf __attribute__ ((cold));
>>>
>>> Do you mean that for each specific application, we extract a common
>>> header file to include all function annotations, and all source files
>>> will include this header file?
>>
>> Yes, something like that...
>> Where do you use the likely_hot/likely_cold logic?
>
> For really cold functions, we predict the branch to be 0.04% taken.
> However, some callee functions are not that extremely cold, and
> predicting them as 0.04% is too aggressive. Likely_cold is for such
> functions, and we predict them as 25% taken (at least we can predict
> the direction right). Vise versa for likely_hot annotation.
>
> Thanks,
> Dehao
>
>>
>> Honza
>>>
>>> Thanks,
>>> Dehao
>>>
>>> >
>>> > Honza
>>> >>
>>> >> thanks,
>>> >>
>>> >> David
>>> >> > Honza


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