From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27092 invoked by alias); 23 Nov 2016 14:14:11 -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 27079 invoked by uid 89); 23 Nov 2016 14:14:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Nov 2016 14:14:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D8EDFC04B328; Wed, 23 Nov 2016 14:13:59 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-19.brq.redhat.com [10.40.204.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uANEDwkl027239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 09:13:59 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uANEDudr020180; Wed, 23 Nov 2016 15:13:56 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uANEDtPB017480; Wed, 23 Nov 2016 15:13:55 +0100 Date: Wed, 23 Nov 2016 14:14:00 -0000 From: Jakub Jelinek To: Martin =?utf-8?B?TGnFoWth?= Cc: Richard Biener , GCC Patches Subject: Re: [RFC][PATCH] Speed-up use-after-scope (re-writing to SSA) Message-ID: <20161123141354.GM3541@tucnak.redhat.com> Reply-To: Jakub Jelinek 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2f58b0f3-6f62-340d-1c92-9e66e2101244@suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg02365.txt.bz2 On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Liška wrote: > I started review process in libsanitizer: https://reviews.llvm.org/D26965 > And I have a question that was asked in the review: can we distinguish 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 turning 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 != 12312) { char my_char; ptr = &my_char; } *ptr = i + 26; return *ptr; we don't notice even the read. Not sure what could be done against that 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 store is result of ASAN_POISON and be able to instead of turning that my_char = _23; into my_char_35 = _23; turn it into: my_char_35 = 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