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.
