http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53547
--- Comment #3 from asharif at gcc dot gnu.org 2012-07-10 12:00:21 UTC --- +cc: Jan Hubicka The use case here represents what happened as we were deploying for Chrome (the browser). Chrome is a moving source base and they did not want to integrate PGO into their build system. Doing so would require their nightly builders to run instrumented Chrome binaries on various devices (example, x86- and arm- based devices), get the PGO data and rebuild the optimized binary. Instead they wanted to generate PGO data offline and use it for slightly newer code. That way they could decouple the generation of PGO data from their build system. That is understandable because changing the build systems for large projects is a tedious task. Currently there are problems with offline PGO: 1. gcc can ICE in certain situations when the profile is out of date. 2. gcc thinks that the mismatched functions execute exactly 0 times and still considers the "program summary" of PGO to be valid (that includes run_max, sum_max, etc.). This misleads gcc into believing that the hot functions are cold (if they have mismatches). gcc should distinguish the case where the edge counts are truly 0, vs. the case where there is a profile mismatch. My patch addresses that. In general, I think PGO will get higher adoption if we make it resilient to slight changes in source code. That way developers can generate good PGO data independently of their nightly builds. Right now the situation is such that gcc's profile files have function ids with checksums instead of function names. If we add a single dummy function to the compilation unit, all the function ids are different and the entire profile file has checksum mismatches. My patch just addresses a part of the problem. If gcc uses function names instead of ids, gcc will be able to tolerate more source changes and I think PGO adoption will increase.
