Re: Thread-safety of a profiled binary (and GCOV runtime library)

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Jul 25, 2016 at 2:35 PM, Nathan Sidwell <nathan@acm.org> wrote:
> On 07/25/16 08:28, Martin Liška wrote:
>
>> I'm also surprised about it :) Let's start without invention of a new
>> flag, I'll work on that.
>
>
> As using atomic add doesn't result in a change to the libgcov interface or
> structures, that's probably the best first approach.  (It also probably gets
> the 90% case).  thanks!
>
>
>> I like the idea sketched by Richard, utilizing TLS and merging counters,
>> which fundamentally the same as merging with existing gcov file.
>> However, I would put this lower priority than the former problem.
>
>
> Richard's suggestion is interesting, and as it solves both problems it may
> be worth a quick experiment?  Perhaps the memory cost isn't so overwhelming?
> After all, it'd be roughly the same per-thread cost as the current gcov
> counters are for the single threaded app they're designed for.

I think in the end implementing both and letting the user choose is
probably best.
So if we add an option make sure to use -fgcov-counter-type={simple,atomic,tls}
and thus sth extensible (with more options).  Not sure if using atomics where
there is native support by default has a small enough overhead to be reasonable
(like on x86_64-linux).  Only measurements will tell, of course.

ISTR some targts have limitations on the TLS segment size as well.

There is also the question about optimization - we go great lengths to ensure
that for example loop store motion applies to counter updates so we get

 old_ctr = values[42];
 for (;;)
   ...
 values[42] = old_ctr + # iterations

using atomics there might show that we have no facility to optimize atomics
at all (given their usual semantics is to include some kind of barrier).

Richard.

> nathan