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 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?
>
> >
> > 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