<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 1:00 PM, Dmitry Vyukov via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">dvyukov added a comment.<br>
<span class=""><br>
> 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.<br>
<br>
<br>
</span>Indeed. That's why behavior of the current profiling counters is undefined.<br>
<span class=""><br>
> Do you have a reference?<br>
<br>
<br>
</span>C/C++ standards does not impose any constraints on thread scheduler. So if we have:<br>
<br>
atomic_store(p, 1);<br>
atomic_store(p, 2);<br>
<br>
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).<br></blockquote><div><br></div><div>I am not sure what 'pretend' here means. It is possible that value '1' is still visible to other threads, or not?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 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)?<br>
<br>
<br>
</span>Because monotonic-atomic-store is still an atomic store, and atomic stores do not race with other atomic operations.<br></blockquote><div><br></div><div>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?  </div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D18164" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18164</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>