[PATCH] Make LLVM profiling thread-safe

[Matthew Dempsky]

On Wed, Jun 26, 2013 at 7:01 PM, Eric Christopher <echristo at gmail.com> wrote:
> Oh totally. I don't have enough of a feel here to know what we should expect.

Seeing as there's not much documentation on how to use it or what it
does, I imagine *most* people don't know what to expect. :P

> Anyone know what other compilers do in this space? What consumers of
> the data would expect? Maybe Matthew has a use case that'll be
> instructive here of what he was trying to accomplish? :)

My immediate use case is fuzzing programs guided by edge coverage, for
which I really only care about distinguishing zero/non-zero values, so
atomic increments aren't even necessary for me since racing increments
will still at least leave a non-zero value.

But generally, I just expect tools to provide correct/precise behavior
by default, and then provide options to trade off between
correctness/precision for performance when necessary.  E.g., on x86-64
there's no extra cost for atomic increments, so they should always be
used.

On ARM, it costs an extra compare and conditional branch instruction
to change the load/increment/store into a LL/SC loop (but no memory
barrier).  ARM's description of LDREX/STREX and exclusive monitors
seems too imprecise to indicate whether looping is necessary for
regular contention or just for context switches/etc, but it seems to
imply the latter to me (otherwise two LL/SC loops could live-lock).

Either way, if someone demonstrates precise profiling slows down their
code too much because of the atomic increments, it shouldn't be hard
to add an ApproximateEdgeProfiling pass variant or something.

My 2c. :)