From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15572 invoked by alias); 7 Feb 2013 17:01:13 -0000 Received: (qmail 15075 invoked by uid 48); 7 Feb 2013 17:00:22 -0000 From: "jakub at gcc dot gnu.org" 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:01: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: jakub at gcc dot gnu.org 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/msg00683.txt.bz2 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*. > #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