http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #25 from Dmitry Vyukov <dvyukov at google dot com> 2013-02-07 17:18:05 UTC --- On Thu, Feb 7, 2013 at 9:00 PM, jakub at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > > 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*. If a memory access is *post* dominated by a memory access to the same location, then the first one can be eliminated even if there are intervening function calls, because it's impossible to make an unaddressable variable addressable again. This is not true for tsan, though.
