[PATCH] D18164: [tsan] Do not instrument reads/writes to instruction profile counters.

[Dmitry Vyukov via llvm-commits]

dvyukov added a comment.

> I think this is already assuming that the original program is race free (i.e., plain load/stores are atomic,). Otherwise the behavior of the original program would also be undefined.


Indeed. That's why behavior of the current profiling counters is undefined.

> Do you have a reference?


C/C++ standards does not impose any constraints on thread scheduler. So if we have:

atomic_store(p, 1);
atomic_store(p, 2);

Elimination of the first store does not affect behavior of the issuing thread (it's dead for the issuing thread). And for other threads we pretend that thread scheduler never gives other threads a chance to observe value 1 (either stores happen very quickly so other threads don't observe the first one, or we have some kind of a cooperative scheduler that does not schedule threads in between these stores, or something along these lines).

> Besides, if 'monotonic' is considered completely 'no-op' (for x86) such as optimizer should not be imposed with any constraints, why Tsan behaves differently here (on x86)?


Because monotonic-atomic-store is still an atomic store, and atomic stores do not race with other atomic operations.


http://reviews.llvm.org/D18164