[PATCH] Skip promotable allocas to improve performance at -O0

[Chandler Carruth]

On Wed, Feb 18, 2015 at 5:19 PM, Anna Zaks <zaks.anna at gmail.com> wrote:

> Hi kcc, samsonov, kubabrecka,
>
> 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.)
>

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.

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.

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).

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]

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.


[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150219/fd91ade2/attachment.html>