AutoFDO profile toolchain is open-sourced

Aditya K
Tue May 12 12:37:00 GMT 2015

Recently we found an ICE while compiling a program with auto-fdo (
The ICE was caused because SSA is not in a valid state when the early inliner is run. The fix was to update_ssa before running the early inliner (
However, it remains to be found out which pass caused the SSA to be in that state, maybe fixing the problem there would be more appropriate.


> Date: Sat, 9 May 2015 16:33:02 +0200
> From:
> To:
> CC:;;;;;;;
> Subject: 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
> stage1?
> 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 :)
> Honza

More information about the Gcc mailing list