my 2c - using instrumentation via calls adds extra 1.5x-2.x slowdown - it indeed saves code size - in LLVM this was done mostly to overcome the compile time problem on huge functions - in GCC we will indeed need this for kasan (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel) - even for kasan this is not a long term solution -- once we finalize the kasan memory layout we'll want to inline the instrumentation. But that may take long time to come there. - it would be nice to have the name prefix configurable from command line (${PREFIX}_load1 instead of __asan_load1) because kasan uses different names already.
On Mon, May 26, 2014 at 7:58 PM, Yury Gribov <y.gri...@samsung.com> wrote: > Hi all, > > This patch adds support for outline Asan instrumentation (i.e. function > calls instead of inline checks). This has been recently added to LLVM to > * reduce long compiler runtimes on large functions with huge (over 10K) > number of memory accesses (http://llvm.org/bugs/show_bug.cgi?id=12653) > * a step to full Kasan support in GCC > * reduce code size overhead > > Implementation is a bit different from LLVM: GCC starts generating function > calls after overflowing the threshold whereas LLVM replaces all > instrumentations once total number is estimated to be larger than treshold. > Making implementations more similar would require bigger rewrite of Asan > which I would prefer to avoid. > > The patch consists of two parts: > * asan_negative_params_1.diff - support for negative parameters > * asan_calls_1.diff - the proper > > Bootstrapped/regtested on x64. > > -Y
