From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45932 invoked by alias); 13 Dec 2016 14:16:09 -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 45913 invoked by uid 89); 13 Dec 2016 14:16:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=tip, re-writing, our X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Dec 2016 14:15:58 +0000 Received: by mail-wm0-f65.google.com with SMTP id g23so18690728wme.1 for ; Tue, 13 Dec 2016 06:15:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nEZvpY4JC0R+AqAGK1sgMtYdfsgIvLPibpyb0NTPLpo=; b=XdMRZsegP56zNCihVzZT/MO3Zc7vQJJZI97siZeSej/CCsQDez5iGcaq/sjwVCN6xC mQvP2nZQZ6gU8w7vkcNAZo+RdDgAycIfFz42Twy9R2GLVSANlwcDLTSdJGT3wuqq2HX8 rU1MUo/o7omv6UqPjncbhX0kYPZtZl+3GwGO5Nho23jPGY7cloiEtC6TPHuo/8+0DKYu gDPoVkQ8OVFM+6EcbweIOCbCJktSQrBpOlVHCArxORPkknqsOwyVRAk4sbvl5MvCW4Q6 yRusdzBtXuCHznAXYSxrWRQtbW7oesfNWyvvkqj8uFo483MhZAQCTA7KbxDWT3EJgX9P FI7A== X-Gm-Message-State: AKaTC0382kbra8+QW3TPQJ9/2nBm7jX6j2vD75C65N6mi52D1QsKpSyHPX+k2kAHpR6SrCLylgTJ+PM/q1r7bA== X-Received: by 10.28.180.214 with SMTP id d205mr3025413wmf.131.1481638556534; Tue, 13 Dec 2016 06:15:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.138.208 with HTTP; Tue, 13 Dec 2016 06:15:56 -0800 (PST) In-Reply-To: <9aa10e31-572a-1939-ba15-528e1fd8adb4@suse.cz> References: <20161102125609.GQ3541@tucnak.redhat.com> <20161102130612.GR3541@tucnak.redhat.com> <774a5d54-30f6-3212-ea4c-21e751356055@suse.cz> <20161116130733.GT3541@tucnak.redhat.com> <469bf86a-e43c-c571-66e4-87db78b6fb11@suse.cz> <20161116162841.GX3541@tucnak.redhat.com> <2f58b0f3-6f62-340d-1c92-9e66e2101244@suse.cz> <20161123141354.GM3541@tucnak.redhat.com> <9aa10e31-572a-1939-ba15-528e1fd8adb4@suse.cz> From: Richard Biener Date: Tue, 13 Dec 2016 14:16:00 -0000 Message-ID: Subject: Re: [RFC][PATCH] Speed-up use-after-scope (re-writing to SSA) To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Jakub Jelinek , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg01161.txt.bz2 On Thu, Dec 8, 2016 at 1:51 PM, Martin Li=C5=A1ka wrote: > On 12/02/2016 01:29 PM, Richard Biener wrote: >> On Thu, Dec 1, 2016 at 5:30 PM, Martin Li=C5=A1ka wrote: >>> On 11/23/2016 03:13 PM, Jakub Jelinek wrote: >>>> On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Li=C5=A1ka wrote: >>>>> I started review process in libsanitizer: https://reviews.llvm.org/D2= 6965 >>>>> And I have a question that was asked in the review: can we distinguis= h between load and store >>>>> in case of having usage of ASAN_POISON? >>>> >>>> I think with ASAN_POISON it is indeed just loads from after scope that= can >>>> be caught, a store overwrites the variable with a new value and when t= urning >>>> the store after we make the var no longer addressable into SSA form, we >>>> loose information about the out of scope store. Furthermore, if there= is >>>> first a store and then a read, like: >>>> if (argc !=3D 12312) >>>> { >>>> char my_char; >>>> ptr =3D &my_char; >>>> } >>>> *ptr =3D i + 26; >>>> return *ptr; >>>> we don't notice even the read. Not sure what could be done against th= at >>>> though. I think we'd need to hook into the into-ssa framework, there = it >>>> should know the current value of the variable at the point of the stor= e is >>>> result of ASAN_POISON and be able to instead of turning that >>>> my_char =3D _23; >>>> into >>>> my_char_35 =3D _23; >>>> turn it into: >>>> my_char_35 =3D ASAN_POISON (_23); >>>> which would represent after scope store into my_char. >>>> >>>> Not really familiar with into-ssa though to know where to do it. >>>> >>>> Jakub >>>> >>> >>> Richi, may I ask you for help with this question? >> >> Probably where we handle the CLOBBER case (rewrite_stmt, maybe_register_= def), >> we do this for -Wuninitialized. >> >> Richard. > > Thanks for the tip, however as the optimization of memory address store += load happens > before we rewrite my_char into SSA, it would be probably hard to guess wh= ich memory > stores and loads should be preserved: > > use-after-scope-20.c.032t.ccp1: > main (int argc, char * * argv) > { > int my_char; > int * ptr; > int _1; > int _11; > > [0.0%]: > if (argc_4(D) !=3D 12312) > goto ; [0.0%] > else > goto ; [0.0%] > > [0.0%]: > ASAN_MARK (2, &my_char, 4); > ptr_8 =3D &my_char; > ASAN_MARK (1, &my_char, 4); > > [0.0%]: > # ptr_2 =3D PHI > _1 =3D argc_4(D) + 26; > *ptr_2 =3D _1; > _11 =3D *ptr_2; > return _11; > > } The SSA renamer sees my_char =3D ASAN_MARK; ptr_8 =3D &my_char; my_char =3D ASAN_MARK; ? It does perform a DOM walk when updating the stmts so simply registering the appropriate current def should do the trick? > I sent updated version of patch to LLVM phabricator: > https://reviews.llvm.org/D26965 > > Hopefully we can cherry pick the patch very soon to our trunk. > > M. > >> >>> Thanks, >>> Martin >>> >