Thread-safe profiling

[Jan Hubicka]

> Jan Hubicka <hubicka@ucw.cz> writes:
> 
> > Trying to imagine what random user would find more discourgrating - ie
> > longer train runs (still probably quite shorter than in ICC) or weird
> > looking mismatches and/or wrong resulting profile, I guess the former is
> > lesser evil and easier to analyze.
> 
> It seems to me that the alternative to thread-safe profiling should
> just be that some nodes are undercounted, when two threads try to
> update the count simultaneously.  It shouldn't be wildly wrong, just
> slightly wrong.

The main problem here is that we optimize amount of counters (by
emitting them only on the non-spanning tree edges) and thus if there are
errors in counts they propagate into all sorts of weird scenarios
including negative number of executions of edges that we report as
profile mismatch.  So as written right now, the profiling simply can't
be used.

We can implement alternative mode emitting enough counters so we on't
propagate the errors, but I am not sure it is worth it - ie it increases
the cost of profiling roughly 3 fold and makes it completely
unverifiable.

Honza
> 
> Ian