> > It is definitly doable (gcov machinery is quite flexible WRT having more > > types of counters). > > Yes, that would introduce back the dropped TOPN counters which I intentionally > dropped.
We could bring back topn counters or the easier dominating vlaue ones and add command line option. However perhaps better in long term would be keep adding mmap ifdefs for targets where it is important... Kernel guys seems to be getting on profile feedback with clang, so we should keep in mind posibility of supporting that as well. > > > We could however also ask users to either resort to > > -fno-profile-values or implement mmap equivalent ifdefs to libgcov if > > they really care about malloc profiling. > > Seems reasonable to me. > > Well, the current approach makes some assumptions on mmap (and malloc), but > they seem reasonable to me. I don't expect anybody building Mingw Firefox PGO > build, > it's likely unsupported configuration. It is possible to build Firefox with mingw on windows and I would expected feedback to work. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw However this is not only about Firefox - we notice problems with Firefox since it is only real word app where we look at PGO more systematically. But we definitly should aim for PGO to be useful for apps of similar complexity. It would be nice to incrase this testing coverage. > > Another observation about the tcmalloc 'malloc' implementation. It hangs in a > PGO build, > but libgcov would be happy if NULL would be returned. Yep, I would expect other folks to try to PGO optimize malloc implementations an we could run into variety of issues... Honza > > Martin > > > > > So personally I do not see this as a must feature (and I think Martin > > was really looking forward to drop the former topn profile > > implementation :) > > > > Another intersting case would be, of course, profiling of kernel... > > > > Honza > > >