Hello, As the subject suggests, the little patch-set that follows this message implements a basic optimization for the Address Sanitizer pass: in the same basic block, it avoids instrumenting an access to a memory region, if that same access has been instrumented before.
As we store instrumented accesses to memory region in a hash table (that uses the new hash-table.h interface), I found it handy to be able to define the hash table entries as a type that has obvious constructors, rather than requiring the user of the hash table entry to write boilerplate code to do the initialization. So it was handy as well to be able to use the new operator to allocate memory for these entries (rather than using malloc + boilerplate initialization code). So I added support for the having hash table entries managed by new/delete in hash-table.h. That's what the first patch does. The second patch is where the real meat of the set is. I deliberately chose to start with the same conservative (and simple) approach used by asan@llvm which is to clear the hash table containing the already-instrumented memory accesses each time we start a new BB or each time we come across a function call. It seems like we could be smarter than that, to allow this optimization to work in inter-BB cases where there is a dominator relationship between BBs containing duplicated memory accesses. But I thought this could be added later, after 4.8. Below is the summary of the patches. [asan] Allow creating/deleting hash table entries with new/delete [asan] Avoid instrumenting duplicated memory access in the same basic block gcc/Makefile.in | 3 +- gcc/asan.c | 366 ++++++++++++++++++--- gcc/hash-table.h | 16 + .../asan/no-redundant-instrumentation-1.c | 70 ++++ 4 files changed, 409 insertions(+), 46 deletions(-) create mode 100644 gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-1.c -- Dodji