On Mon, 2013-04-22 at 13:13 -0700, Xinliang David Li wrote: > There is a similar patch (in google branches) from Rong Xu which > enables atomic profile counter update. > > http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00072.html
Thanks, David! We'll take a look. > > On Mon, Apr 22, 2013 at 12:59 PM, Bill Schmidt > <wschm...@linux.vnet.ibm.com> wrote: > > Six years ago, Michael Matz proposed a patch for generating profile > > instrumentation in a thread-safe manner: > > > > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html > > > > Reading through the thread, I saw a few minor objections, but nothing to > > indicate the patch should be withdrawn. However, apparently the changes > > were never made. > > > > I'm curious about the history here. What was the reason for abandoning > > this? Was a better alternative found? Were all the counters made > > thread-local? > > > > My reason for asking involves a large heavily-threaded application that > > is improved by feedback-directed optimization on some platforms, but not > > on others. One theory is that a defective profile is generated due to > > counter dropouts from contention. I'm somewhat skeptical about this > > given that some platforms seem to do well with it, but it's possible. > > Do you see lots of messages about insane profile data (under > -fprofile-correction)? Most of the such messages we see (in our large > multi-threaded applications) show only marginal errors. > We're still waiting on that data. We don't have direct access to the application so we're having to work at some remove. When we asked for it the first time, the build logs had unfortunately been purged. > > > I'm hopeful that knowing why the thread-safe profiling patch wasn't > > implemented will give us more of a clue. > > You can try out Rong's patch. He plan to submit it to trunk soon. Much obliged! Bill > > thanks, > > David > > > > > Thanks for any help! > > > > Bill > > >
