This is an archive of the discontinued LLVM Phabricator instance.

[InstrProfiling] Fix data race on profile counters by using AtomicRMW.
Needs ReviewPublic

Authored by samsonov on Jul 28 2015, 3:14 PM.

Details

Reviewers
dnovillo
bogner
Summary

Since we introduced counters for functions in COMDAT sections (e.g.
inline functions from STL headers), these headers can easily be
incremented concurrently by multiple threads. Replace load-add-store
with a single "atomicrmw add" with monotonic memory ordering.

Diff Detail

Event Timeline

samsonov updated this revision to Diff 30864.Jul 28 2015, 3:14 PM
samsonov retitled this revision from to [InstrProfiling] Fix data race on profile counters by using AtomicRMW..
samsonov updated this object.
samsonov added reviewers: dnovillo, bogner.
samsonov added a subscriber: llvm-commits.
dnovillo edited edge metadata.Jul 29 2015, 3:21 PM

I'm confused. Your change seems to be modifying the semantics of the expansion. Could you elaborate on why this is safe? The code used to expect uses of the increment instruction.

What kind of uses do you refer to? InstrProfIncrementInst we're replacing has type "void", so it doesn't return any value that can be consumed.

What kind of uses do you refer to? InstrProfIncrementInst we're replacing has type "void", so it doesn't return any value that can be consumed.

Yeah, that's what's confusing me. Why was the code before calling RAUW?

Other than that, your change looks fine to me. But there's clearly something I'm not quite understanding here. I'd like Justin to chime in.

If your intention is to fix data races rather than to improve precision, then the more straightforward fix would be:

atomic_store_n(&cnt, atomic_load_n(&cnt, __ATOMIC_RELAXED) + 1, __ATOMIC_RELAXED);

It should not affect performance of the generated code (unless there is a bug in atomic codegen).