<div dir="ltr">Filed <a href="https://code.google.com/p/chromium/issues/detail?id=484711">https://code.google.com/p/chromium/issues/detail?id=484711</a><br></div><br><div class="gmail_quote">вт, 28 апр. 2015 г. в 22:54, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 28, 2015 at 10:48 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Apr 28, 2015 at 10:23 AM, Timur Iskhodzhanov <span dir="ltr"><<a href="mailto:timurrrr@google.com" target="_blank">timurrrr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote">вт, 28 апр. 2015 г. в 20:03, Alexey Samsonov <<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>>:<span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 11, 2015 at 8:38 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sat, Apr 11, 2015 at 2:36 PM, Timur Iskhodzhanov <span dir="ltr"><<a href="mailto:timurrrr@google.com" target="_blank">timurrrr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">__attribute__((no_instrumentation)) ?  Sounds like a perfect fit for the job</p></blockquote><div><br></div></span><div>However, IIRC, Clang folks wanted positive attributes ("sanitize_address", "sanitize_memory" etc.) on LLVM</div><div>functions, not sure "no_instrumentation" will be accepted. Otherwise we will have to emit "sanitize_coverage"</div><div>attribute on all functions that need to be instrumented, and that would be somewhat unfortunate.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>So, essentially you need an attribute to disable coverage instrumentation of a particular function</div><div>(as ASan instrumentation is already disabled), right?</div></div></div></div></blockquote><div><br></div></span><div>Yes, or...</div><div>What I really want is a way to tell the compiler "hey, I don't want this function to do any memory accesses other than those required by its code".</div><div>Do you think we should maybe have an attribute for exactly this purpose?</div></div></div></blockquote><div><br></div></span><div>Oh, so this would be not really relevant to sanitizers. This attribute makes sense, but... how would you enforce it? It will have to be supported by</div><div>all sanitizers, coverage instrumentation, profiling, and maybe even optimization passes.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yeah, I don't know how we would quantify "memory accesses except those required by the code". Does this attribute ban load speculation, where I hoist the load to known addressable memory out of a loop?</div><div><br></div><div>I think taking the boring path of adding no_sanitize_coverage to clang and sanitize_coverage to LLVM is probably the best, most straightforward thing to do, even if it's not the least work.</div></div></div></div>
</blockquote></div>