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
