From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29093 invoked by alias); 7 Feb 2013 17:18:55 -0000 Received: (qmail 28633 invoked by uid 55); 7 Feb 2013 17:18:07 -0000 From: "dvyukov at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's Date: Thu, 07 Feb 2013 17:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: dvyukov at google dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg00690.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #25 from Dmitry Vyukov 2013-02-07 17:18:05 UTC --- On Thu, Feb 7, 2013 at 9:00 PM, jakub at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 > > --- Comment #24 from Jakub Jelinek 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.