This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Asan static optimization (draft)
- From: Dmitry Vyukov <dvyukov at google dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Yury Gribov <y dot gribov at samsung dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Marek Polacek <polacek at redhat dot com>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail 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: Fri, 8 Aug 2014 14:43:12 +0400
- Subject: Re: [PATCH] Asan static optimization (draft)
- Authentication-results: sourceware.org; auth=none
- References: <53E4A5D1 dot 8050007 at samsung dot com> <20140808103744 dot GP7393 at tucnak dot redhat dot com>
On Fri, Aug 8, 2014 at 2:37 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Aug 08, 2014 at 02:26:25PM +0400, Yury Gribov wrote:
>> 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 (*).
>
> Thanks for working on it, I've just quickly skimmed it and it looks
> reasonable.
>
> Similar optimization could be used for tsan builtins, or some of the ubsan
> builtins (which is the reason why the pass is called sanopt).
That would be great.
Note that tsan optimizations must be based around a different
criteria. Any unlock/release operations must reset set of already
checked locations. Also tsan does not care about non-escaped to other
threads variables; e.g. it does not care about
local_stack_array[rand()] expressions, while asan does.
>> 3) in addition to redundant check removal, we could also move duplicate
>> checks from e.g. branches of if-statement to their dominators.
>
> For that you'd need to be extra careful, you would need to avoid doing that
> if any path doesn't contain the check, or if there are calls that e.g. could
> not return (abort/exit/have infinite loop) in between, etc.
>
> Jakub