From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22297 invoked by alias); 19 Aug 2014 23:43:19 -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 22191 invoked by uid 89); 19 Aug 2014 23:43:18 -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-f177.google.com Received: from mail-vc0-f177.google.com (HELO mail-vc0-f177.google.com) (209.85.220.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 19 Aug 2014 23:43:16 +0000 Received: by mail-vc0-f177.google.com with SMTP id hy4so8128059vcb.8 for ; Tue, 19 Aug 2014 16:43:13 -0700 (PDT) X-Received: by 10.52.27.16 with SMTP id p16mr6049051vdg.14.1408491793712; Tue, 19 Aug 2014 16:43:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.52 with HTTP; Tue, 19 Aug 2014 16:42:53 -0700 (PDT) In-Reply-To: References: <53E4A5D1.8050007@samsung.com> From: Konstantin Serebryany Date: Tue, 19 Aug 2014 23:43: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/msg01967.txt.bz2 On Mon, Aug 18, 2014 at 1:05 PM, Yuri Gribov wrote: > On Fri, Aug 15, 2014 at 10:34 PM, Konstantin Serebryany > wrote: >> If this is -O1 or higher, then most (but not all) of your cases >> *should* be optimized by the compiler before asan kicks in. > > You mean hoisting memory accesses from branches? > Sure, the tests are simplified beyond all limits. > On the other hand even basic aliasing constraints > would obviously prevent optimization of pointer accesses > (but not of Asan checks!). Exactly. I am interested in full non-simplified tests where the regular optimizer has no chances, but asan- (tsan-, msan-) specific optimizer has. > >> (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). > > Thanks for mentioning this, I'll try to experiment > with moving Asan pass across the compilation pipeline and > report my findings. > >> I am mainly interested in cases where the general optimizer can not >> possibly improve the code, >> but asan opt can eliminate redundant checks. > > As I mentined, I believe that aliasing may often restrict > optimizer's code hoisting ability. > And we certainly need Asan opt for combining checks. > >>> 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 > > Ok, so I'll firstly post tests on wiki and explicitely reference their > origin when submitting patches. > >>> 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. > > Could you give more details? How would > use-after-free/init-order-fiasco influence verification of redundant > elimination? Consider this: extern void foo(int *); int *a = new int [10]; foo(a); ... = a[5]; here, a[5] can not go out of bounds and regular Java-oriented algorithms will mark this as safe. However, foo() may delete 'a' and we'll have a use-after-free here. --kcc