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

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-07 17:00:17 UTC ---
(In reply to comment #23)
> #1 afaict, the asan pass happens in the middle of the gcc optimization flow.
> imho it should happen as late as possible so that the instrumentation 
> happens on fully optimized code. 

Our current plan for 4.9 is add __builtin_asan_mem_test (address, length,
is_write) or similar builtin, where the current asan pass would just insert
these builtins.  Then, we'd teach the alias oracle and other code about these
builtins (that they shouldn't be optimized away, unless dominated by similar
test on the same address with same or bigger length, without an intervening
call that could free memory, and that they on the other side don't modify any
memory), teach the vectorizer how to vectorize these builtins and look at other
passes where it might prevent some optimizations (I guess vectorization will be
the most important though).  And, finally have some later pass that will do the
optimization Dodji just wrote, but on the builtins in the IL, with some
propagation etc. (and could handle tsan builtins too), and then lower this
special asan builtin to the shadow memory load + test + __asan_report*.

> #2 asan speed is very sensitive to quality of regalloc. It would be interesting
> (and useful anyway) to implement zero-offset-shadow
> (https://code.google.com/p/address-sanitizer/wiki/ZeroBasedShadow)
> and see how much it helps with performance. 
> If more than clang's 5% -- we have issues with regalloc, otherwise see #1