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

[Xinliang David Li via llvm-commits]

On Thu, Mar 17, 2016 at 1:00 PM, Dmitry Vyukov via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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).
>

I am not sure what 'pretend' here means. It is possible that value '1' is
still visible to other threads, or not?



>
> > 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.
>

Sorry it may seem obvious to you, but here is the puzzle: suppose the two
cases I mentioned produces *identical* code in the final binary -- it
either has race or not, but not both.  HoweverTsan says it has race if
produced from one form of IR while no race from another?

thanks,

David


>
>
> http://reviews.llvm.org/D18164
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160317/c27894a7/attachment.html>