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

[Anna Zaks via llvm-commits]

zaks.anna added a comment.

> It is not about this assumption, but more about racy counter updates not being a problem practically  (other than the precision of the profile data might be 

>  affected slightly in practice).


"Racy counter updates not being a problem practically" assumes atomicity of the loads and stores. My understanding is that we assume that the loads and stores are atomic and on top of that we do not care about the precision of the profile data.

> > You seem to assume that marking the profiler memory accesses as monotonically atomic will degrade performance. Why? If that's the case then there is a 

> 

> >  bug in llvm optimizer, and we need to fix it.

> 

> 

> It might -- at least we should measure it. Note that instrumentation run is already pretty slow, so we need to be careful not to regress it.


Which architecture do you worry about? If these are pointer sized reads and writes, which are atomic on x86 and ARM, the monotonic loads and stores will turn into no-ops.

> Do they turn on all sanitizers + profiling or just certain combinations? I am just trying to understand the use case here.


The question is if we should detect the profiler and sanitizer being turned on at the same time and error out in the driver or if we should allow it. I do not see a reason to disallow this. To answer your other question, most of the sanitizers cannot be turned on simultaneously.


http://reviews.llvm.org/D18164