<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 11:38 AM, Anna Zaks <span dir="ltr"><<a href="mailto:zaks.anna@gmail.com" target="_blank">zaks.anna@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">zaks.anna added a comment.<br>
<span class=""><br>
> 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<br>
<br>
>  affected slightly in practice).<br>
<br>
<br>
</span>"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.<br>
<span class=""><br></span></blockquote><div><br></div><div><br></div><div>Right -- the point about racy update I brought up is irrelevant here. </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>
</span>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.<br></blockquote><div><br></div><div><br></div><div>We are probably talking about different things here.  My main concern is the additional constraints imposed on the optimizer that can penalize optimizations (no-op or not on a target). For instance, memory dependence analysis treats Monotonic loads as 'read+write' (ModRef). This can certainly affect DSE, etc.  On x86, the pseudo instruction generated for Monotonic load is ACQUIRE_MOV with Volatile bit set. It might have some impact too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Do they turn on all sanitizers + profiling or just certain combinations? I am just trying to understand the use case here.<br>
<br>
<br>
</span>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.<br></blockquote><div><br></div><div> Since it is known certain combinations of instrumentions do not work together, why not documenting the behavior and let user filter out the false warnings? Supporting all corner case combinations adds additional maintenance cost (and costs can add up).   </div><div><br></div><div>Back to your proposal to use Monotonic load. It does not fix the actual race (to fix the race, atomic fetch_add instruction is needed) nor can it silence tsan.</div><div> </div><div>David</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>