This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [google] Add options to pattern match function name for hotness attributes
On Mon, Jun 4, 2012 at 6:24 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >> Actually Dehao also plans to teach the static predictor to understand
>> >> standard library functions more (e.g IO functions) and add more naming
>> >
>> > How this differ from annotating the library?
>>
>> I find them more suitable to be compiler heuristic than being
>> function's attribute -- attribute is a much stronger assertion.
>
> Why so? Special matching the function names in compiler is pretty much
> the same thing as annotating them in the source, right?
Compiler can choose to do fine grained tuning based on heuristics
which can be hard for user to do/maintain using annotation. For
instance, we provide user __builtin_expect to annotate branches, but
not a more general builtin to annotate the branch with specific
probabilities -- the latter is taken care of by the compiler.
thanks,
David
>>
>> >
>> > There are indeed quite some possibilities to do about library calls....
>> >
>> > One thing I always wondered about is how to tell predictor that paths containing
>> > heavy IO functions don't need to be really opimized to death, since their execution
>> > time is dominated by the IO...
>> >
>>
>> Yes -- if branch predictor does the right thing and if function
>> splitter is powerful enough, the IO code can be outlined and optimized
>> for size :)
>
> We have infrastructure for optimizing for size regions of functions, so this should
> be easy. With flag_reorder_blocks_and_partition we can even "outline"
> but problem with these things is that they do not really match the usual vision
> of profile prediction...
>
> Honza
>>
>>
>> >> based heuristics such as 'error, success, failure, fatal etc).
>> >
>> > yeah, this is also mentioned by some branch prediction papers. It is bit kludgy
>> > in nature (i.e. it won't understand programs written in Czech language) but it
>> > is an heuristics after all.
>> >
>>
>> right.
>>
>> thanks,
>>
>> David
>>
>> > Honza
>> >>
>> >> thanks,
>> >>
>> >> David
>> >>
>> >> > Honza
>> >> >>
>> >> >> thanks,
>> >> >>
>> >> >> David
>> >> >> > Honza