<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 5:19 PM, 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"><div id=":b5p" class="a3s" style="overflow:hidden">Hi kcc, samsonov, kubabrecka,<br>
<br>
Currently, the ASan executables built with -O0 are unnecessarily slow. The main reason is that ASan instrumentation pass inserts redundant checks around promotable allocas. These allocas do not get instrumented under -O1 because they get converted to virtual registered by mem2reg. With this patch, ASan instrumentation pass will only instrument non promotable allocas, giving us a speedup of 39% on a collection of benchmarks with -O0. (There is no measurable speedup at -O1.)<br></div></blockquote></div><br>I don't really like this approach because it will introduce false negatives. We have even been helped in debugging "miscompiles" of incorrect code by running asan at -O0 to point out where the stack variables.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I proposed a long time ago what I think the correct fix is for this. We really need to split (at least mentally) ASan into three "phases". One which instruments all accesses to function local allocas by inserting bounds checking, and one which instruments all other memory accesses. Finally, we insert redzones and update shadow memory only for the allocas for which we cannot prove that all accesses are bounds checked.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the first phase (instrumenting with bounds checks) we should do quite some analysis to *prove* when the access is either in-bounds or out-of-bounds, and to "constant fold" the checks (delete when in-bounds, and turn into unconditional checks when out-of-bounds).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Once we do this, we should also run some optimization passes after ASan at higher -O levels to handle any simplifications of the bounds checks that we can't just eliminate when doing the instrumentation.[1]</div><div class="gmail_extra"><br></div><div class="gmail_extra">The advantages of this are massive IMO. We should see very significant memory usage and runtime improvements from this at all -O levels, especially -O0, and at no false negative rate. I have long wanted to actually implement this, but I have no time. =] I don't think it would be too hard though, and lots of the fancy things can be done incrementally.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] Note that it might be interesting to as a matter of principle have ASan introduce naive bounds checks, and to rely entirely on optimizers to remove them. This would help ensure that we actually have good bounds check elimination in tree (something Philip and others might really be happy about) and would simplify the instrumentation. Then we could just handle easy cases at -O0 where the constant folder is probably all we need.</div></div>