[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

["dodji at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309

Dodji Seketeli <dodji at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29366|0                           |1
        is obsolete|                            |

--- Comment #22 from Dodji Seketeli <dodji at gcc dot gnu.org> 2013-02-06 15:02:44 UTC ---
Created attachment 29370
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29370
Candidate patch to avoid duplicated intra bb instrumentation

> Trying this patch: 
> % cat inc.cc
> void foo(int *a) {
>   (*a)++;
> }
> % gcc -fsanitize=address -O2 inc.cc -S -o - | grep __asan_report
>         call    __asan_report_load4
>         call    __asan_report_store4
> % clang -fsanitize=address -O2 inc.cc -S -o - | grep __asan_report 
>         callq   __asan_report_load4
> % 
> 
> Is this test expected to work (have one __asan_error call) with this patch?

The patch indeed (naively) considers read and write accesses as being
different, you are right.  I am attaching a patch that does not, and
that generates just one __asan_report call here.

I'd be nice to know if that makes any change to ...

> First results with the patch (c-only tests, train data):
>                              orig          patched
>            401.bzip2,        89.60,        90.10,         1.01
>              429.mcf,        23.50,        23.90,         1.02
>            456.hmmer,       181.00,       145.00,         0.80
>       462.libquantum,         1.64,         1.64,         1.00
>          464.h264ref,       249.00,       249.00,         1.00
>             433.milc,        20.10,        20.00,         1.00
>              470.lbm,        37.20,        37.20,         1.00
>          482.sphinx3,        17.50,        17.50,         1.00
> 
> significant speedup on 456.hmmer, no difference elsewhere. 

... this.  Hopefully, if subsequent intrumentations on same BB on
read/write are considered redundant now, we should see some speed
difference on more tests.

> 3 benchmarks fail to build: 

> Error: 1x403.gcc 1x445.gobmk 1x458.sjeng
> resource.c:431:1: internal compiler error: in
> update_mem_ref_hash_table, at
> asan.c:460

The updated patch hopefully addresses that too.

Thank you for doing this!