From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17392 invoked by alias); 15 Aug 2014 18:34:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 17380 invoked by uid 89); 15 Aug 2014 18:34:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f171.google.com Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 15 Aug 2014 18:34:23 +0000 Received: by mail-vc0-f171.google.com with SMTP id hq11so3352613vcb.2 for ; Fri, 15 Aug 2014 11:34:21 -0700 (PDT) X-Received: by 10.52.99.106 with SMTP id ep10mr1429762vdb.73.1408127661299; Fri, 15 Aug 2014 11:34:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.52 with HTTP; Fri, 15 Aug 2014 11:34:01 -0700 (PDT) In-Reply-To: References: <53E4A5D1.8050007@samsung.com> From: Konstantin Serebryany Date: Fri, 15 Aug 2014 18:34:00 -0000 Message-ID: Subject: Re: [PATCH] Asan static optimization (draft) To: Yuri Gribov Cc: Yury Gribov , GCC Patches , Jakub Jelinek , Marek Polacek , Dmitry Vyukov , Dodji Seketeli , Viacheslav Garbuzov Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg01618.txt.bz2 On Thu, Aug 14, 2014 at 11:55 PM, Yuri Gribov wrote: > On Thu, Aug 14, 2014 at 8:53 PM, Konstantin Serebryany > wrote: >> In order for your work to be generally useful, I'd ask several things: >> - Update https://code.google.com/p/address-sanitizer/wiki/CompileTimeOptimizations >> with examples that will be handled > > Done (to be honest I only plan to do full redundancy elimination for > now, hoisting would hopefully follow later). Note I'm still > experimenting so there may be some changes in actual implementation. Thanks. if we are running -O0, we should not care about optimizing asan instrumentation. If this is -O1 or higher, then most (but not all) of your cases *should* be optimized by the compiler before asan kicks in. (This may be different for GCC-asan because GCC-asan runs a bit too early, AFAICT. Maybe this *is* the problem we need to fix). If there is a case where the regular optimizer can optimize the code before asan but it doesn't -- we should fix the general optimizer or the phase ordering instead of enhancing asan opt phase. I am mainly interested in cases where the general optimizer can not possibly improve the code, but asan opt can eliminate redundant checks. > >> - Create small standalone test cases in C >> - Don't put the tests under GPL (otherwise we'll not be able to reuse >> them in LLVM) > > I already have a bunch of tests (which I plan to extend further). How > should I submit them s.t. they could be reused by LLVM? Maybe just start accumulating tests on the CompileTimeOptimizations wiki (as full functions that one can copy-paste to a .c file and build)? Once some new optimization is implemented in a compiler X, we'll copy the test with proper harness code (FileCheck/dejagnu/etc) to the X's repository > >>>> make sure that sanopt performs conservative optimization >> Yes. I don't know a good solution to this problem, which is why we did >> not attack it before. >> Increasing asan speed will save lots of CPU time, but missing a single software >> bug due to an overly aggressive optimization may cost much more. > > Yeah. I thought about manually inspecting optimizations that are > performed for some large files (e.g. GCC's asan.c) and maybe doing > some random verifications of Asan trophies > (http://code.google.com/p/address-sanitizer/wiki/FoundBugs). Ideally > we'd have some test generator but making a reasonable one for C sounds > laughable. Perhaps there is some prior work on verification of Java > range checks optimizers? There is ton of work for range check optimizers, but none of that fully applies to asan, since asan also checks use-after-free and init-order-fiasco. > > -Y