On Thu, Aug 11, 2011 at 7:21 AM, Mike Hommey <mhom...@mozilla.com> wrote: > On Thu, Aug 04, 2011 at 04:05:25PM +0200, Mike Hommey wrote: >> Hi, >> >> We (Mozilla) are trying to get the best of the ARM toolchain for our >> Android build. I recently built an Android Native-code Development Kit >> with GCC 4.6.1 and binutils 2.21.53, instead of GCC 4.4.3 and binutils >> 2.19 that come with the default NDK. >> >> LTO doesn't work at all, I'm getting an ICE that looks like the one from >> bug 41159. >> >> FDO however, works, but sadly, the resulting build is not only quite >> bigger, it's also slower on some tests (the Sunspider javascript >> benchmark). While we have seen improvements on other tests (most >> notably, the V8 benchmark is much faster) by switching to GCC 4.6 (that >> is, without FDO), FDO doesn't seem to bring anything on the table. It >> even seems to bring performance regression. > > Maybe I have an idea as to why FDO doesn't work so well. Does the > instrumentation code support running several times in parallel (as in, > several processes with the instrumented code running concurrently)?
gcc supports profile merging from multiple runs -- but there is no synchronization on profile file update, but it will become a problem only when all the concurrently running processes are existing at the same time (and dumping profile data to the same gcda file at the same time). Similarly, there are data races in profile counter update for multi-threaded programs, in practice it is not a big issue (-fprofile-correction option needs to be turned on in profile-use). David > > Cheers, > > Mike >
