<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 11:41 AM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</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>
> It is not about this assumption, but more about racy counter updates not being a problem practically<br>
<br>
<br>
</span>Choosing an incorrect code all others equal does not look like the right approach to me.<br></blockquote><div><br></div><div><br></div><div>I don't agree with you about the 'incorrect code' part.</div><div><br></div><div>Having said that, I think it is reasonable to introduce an option to enable atomic profile counter update.  Tsan can then be safely combined with that.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></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>
> 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.<br>
<br>
<br>
</span>Again, is that's the case, that's a very real bug in llvm codegen that needs to be fixed. Patching all uses of atomic operations in the world to work around that bug is not going to scale (and just wrong).<br>
<br>
<br>
<a href="http://reviews.llvm.org/D18164" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18164</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>