This is the mail archive of the 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: AutoFDO profile toolchain is open-sourced

> > Yes, it will. But it's not well tuned at all. I will start tuning it
> > if I have free cycles. It would be great if opensource community can
> > also contribute to this tuning effort.
> If you could outline portions of code which needs tuning, rewriting, that will help get started in this effort.

Optimization passes in GCC are generally designed to work with any kind of edge profile they get.
There are only few cases where they do care about what profile is around.

At the moment we consider two types of profiles - static (guessed) and FDO. For
static one we shut down use of profile info for some heuristics - for example
we do not expect loop trip counts to be reliable in the profiles because they
are not.  You can look for code checking profile_status_for_fn.

Auto-FDO does not have special value for profile_status_for_fn and it goes with
same code paths for FDO.  Dehao has some patches for Auto-FDO tuning but my
impression is that he got mostly got around by just makng optimizer bit more
robust for nonsential profiles that is always good, since even FDO profiles can
get wrong.  BTW, Dehao, do you think you can submit these changes for this

I suppose in this case we have yet another kind of profile that is less reliable than
FDO and we need to start by simply benchmarking and looking for cases where this profile
gets worse and handle them one by one :)


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