From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14980 invoked by alias); 7 Feb 2013 05:02:35 -0000 Received: (qmail 14664 invoked by uid 48); 7 Feb 2013 05:01:56 -0000 From: "kcc 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 05:02: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: kcc 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/msg00612.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #23 from Kostya Serebryany 2013-02-07 05:01:53 UTC --- with the patch from comment 22 (all benchmarks, ref data): orig patched 400.perlbench, -1.00, 1244.00, -1244.00 401.bzip2, 1189.00, 1137.00, 0.96 403.gcc, 754.00, 750.00, 0.99 429.mcf, 611.00, 610.00, 1.00 445.gobmk, 1211.00, 1167.00, 0.96 456.hmmer, 1834.00, 1501.00, 0.82 458.sjeng, 1353.00, 1288.00, 0.95 462.libquantum, 478.00, 480.00, 1.00 464.h264ref, 1880.00, 1836.00, 0.98 471.omnetpp, 621.00, 621.00, 1.00 473.astar, 766.00, 763.00, 1.00 483.xalancbmk, 515.00, 517.00, 1.00 433.milc, 631.00, 625.00, 0.99 444.namd, 538.00, 538.00, 1.00 447.dealII, 716.00, 719.00, 1.00 450.soplex, 421.00, 415.00, 0.99 453.povray, 433.00, 429.00, 0.99 470.lbm, 415.00, 411.00, 0.99 482.sphinx3, 1377.00, 1343.00, 0.98 The average speedup is similar to what we saw with equivalent optimization in clang. Strangely, 400.perlbench fails with a warning when built with trunk but passes with this patch. I did not investigate this further yet. If we are looking for greater speedup we need to perform more comprehensive research. I have two wild guesses (not supported by any data). #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. #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