This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Move Asan instrumentation to sanopt pass
- From: Richard Biener <richard dot guenther 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>, Konstantin Serebryany <kcc at gcc dot gnu dot org>, Dmitry Vyukov <dvyukov at google dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>, Marek Polacek <polacek at redhat dot com>
- Date: Tue, 22 Jul 2014 15:57:34 +0200
- Subject: Re: [PATCH] Move Asan instrumentation to sanopt pass
- Authentication-results: sourceware.org; auth=none
- References: <53C922DE dot 6020000 at samsung dot com>
On Fri, Jul 18, 2014 at 3:36 PM, Yury Gribov <y.gribov@samsung.com> wrote:
> Hi all,
>
> Attached patch delays generation of Asan memory checking code
> until sanopt pass. This is a first step towards global static analysis
> of Asan instrumentation which would allow to
> * remove redundant instrumentations
> * aggregate adjacent Asan checks
> * move invariant checks from loops
>
> The patch also changes the logic behind
> asan-instrumentation-with-call-threshold
> parameter to more closely match LLVM.
>
> The patch splits build_check_stmt routine to two parts. The first one
> (called from asan0/asan passes) inserts calls to internal functions
> ASAN_LOAD and ASAN_STORE. The second expands those to inline checks
> (in asan_expand_check_ifn).
>
> Here are some obvious disadvantages:
> * passing additional info via hidden parameter of
> ASAN_{LOAD,STORE} is ugly but I'm not sure how to do this better
> * delayed expansion runs after all optimization passes
> so inlined Asan checks will not get a chance to be
> CSE-ed, etc.; this may probably be solved by moving sanopt earlier
> in the pipeline. BTW I haven't experienced notable slowdowns in my
> experiments.
> * passing program pointers to ASAN_{LOAD,STORE} may damage alias analysis
> because all pointers will now escape;
Ugh.
> I probably could
> provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
> even EAF_UNUSED for these functions but this does not seem
> to be supported in current middle-end.
Simply add the "fn spec" attribute to the functions?
Richard.
> The patch was bootstrapped, regtested and asan-bootstrapped on x64.
>
> Is this ok for trunk?
>
> -Yury