On Mon, Jul 25, 2016 at 2:35 PM, Nathan Sidwell <nat...@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
