This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Asan static optimization (draft)
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Marek Polacek <polacek at redhat dot com>, Dmitry Vyukov <dvyukov at google dot com>, Dodji Seketeli <dodji at redhat dot com>, Yuri Gribov <tetra2005 at gmail dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>
- Date: Thu, 14 Aug 2014 09:53:19 -0700
- Subject: Re: [PATCH] Asan static optimization (draft)
- Authentication-results: sourceware.org; auth=none
- References: <53E4A5D1 dot 8050007 at samsung dot com>
Indeed, thanks for working on this.
We've been wanting such optimization phase from day one, but never got
to implementing it (except for a few simple ones).
There have been several attempts outside of our team to do such
optimizations, but none of them made it to llvm trunk.
In order for your work to be generally useful, I'd ask several things:
- Update https://code.google.com/p/address-sanitizer/wiki/CompileTimeOptimizations
with examples that will be handled
- Create small standalone test cases in C
- Don't put the tests under GPL (otherwise we'll not be able to reuse
them in LLVM)
>> make sure that sanopt performs conservative optimization
Yes. I don't know a good solution to this problem, which is why we did
not attack it before.
Increasing asan speed will save lots of CPU time, but missing a single software
bug due to an overly aggressive optimization may cost much more.
We can do a detailed analysis of *simple* peephole-like optimizers,
but *proving* that a complex optimizer does not remove needed checks
is hardly practically possible.
On Fri, Aug 8, 2014 at 3:26 AM, Yury Gribov <email@example.com> wrote:
> Hi all,
> I have been working on Asan global optimization pass lately. The goal is to
> remove redundant Asan checks from sanitized code. This should hopefully
> reduce Asan's speed/size overhead (which is currently ~2x). The patch is not
> yet ready for trunk (e.g. I haven't done bootstrap, etc. but Asan testsuite
> passed wo errors) but I thought I'd send it for preliminary review of
> algorithm and data structures (*).
> Current implementation (based on existing sanopt pass) uses a simple
> iterative intra-procedural dataflow to compute information about living
> checks. For each pointer we track the size of memory that was already
> checked for it. During dataflow iterations, living checks are merged at
> blocks start in a natural way.
> I decided to keep current (local) Asan optimizations because they reduce
> compilation time by dropping many obviously redundant checks much earlier in
> the compilation pipeline.
> Current results seem to be encouraging: the pass was able to remove 112
> checks (out of 1768) in gcc/asan.c without significant increase in sanopt
> pass runtime.
> Before upstreaming this code, I plan to
> 1) develop extensive set of tests to make sure that sanopt performs
> conservative optimization i.e. does not remove checks too agressively (I
> guess this is a critically important prerequisite so any suggestions are
> 2) disable optimizations for very large functions to avoid unbearable
> compile times
> 3) do detailed performance and efficiency measuments for Asan-bootstrap
> I also have some ideas for improving this code (and I'm certainly open to
> suggestions from community):
> 1) propagating checking information through assignments and PHI-nodes (and
> maybe even pointer arithmetic) should improve efficiency
> 2) ditto for optimization of symbolic ranges; actually this looks like a
> relatively easy addition to current code (I just need to keep a list of
> checked symbolic ranges to check_info structure)
> 3) in addition to redundant check removal, we could also move duplicate
> checks from e.g. branches of if-statement to their dominators.
> (*) The patch relies on some additional changes in hash-table and CFG which
> have not yet been upstreamed so it won't go with current trunk.