This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FDO and LTO on ARM


On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote:
> > 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).

Are there known quirks with threads and dlopen() ?

To avoid the problem mentioned above, I configured Firefox to use only
one process. But in that setup, I only get partial instrumentation data.
For example, I get instrumentation data for cairo, but not for our
layout engine. I do however get layout engine instrumentation data with
the same build if I enable multiple processes (but then I hit the
problem that multiple processes updating the same profile data is not
properly supported). The main difference between the main and the child
process is that the main process starts as a dalvik instance, dlopen()s
native code, which itself dlopen()s all our libraries. The child process
is just an executable that is linked against all these libraries.

Cheers,

Mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]