On Fri, Jul 18, 2014 at 3:36 PM, Yury Gribov <y.gri...@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
