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!
