From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79160 invoked by alias); 25 Apr 2019 12:39:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 79152 invoked by uid 89); 25 Apr 2019 12:39:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=fuck, knowing, designing X-HELO: mail-lj1-f173.google.com Received: from mail-lj1-f173.google.com (HELO mail-lj1-f173.google.com) (209.85.208.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Apr 2019 12:39:16 +0000 Received: by mail-lj1-f173.google.com with SMTP id z26so2340652ljj.2 for ; Thu, 25 Apr 2019 05:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YhJcSX2d+gEFLONziA3sgzYEiMhriybeULeZIWnEavE=; b=p7Yg6Y6sUZqGS2bAnlYN22w88K8iBp+zi7GuEjIGal3fJUK2Tw9bdYZV42di9XLe3t zJLtxVU4q5LLXK9EC6NvLtV49Ttupbcl73/FebTROIgZAwvi3lPdAdY9KgmJpQz0vYbG L7BfQnNS99Er6Ib9sKYT3F5Wevd0x299CfIn049hqS4/Rn11jfwJztl6n27V9zEB0Olt ZOx2bHauCeuultoW0SmwzP05OSBO6MCVP+ws5u+VhsJOcrqrtZCOyKMLzEi8UedAkhzU 5/wE1QHJj8ObeR6Xi68LYyKI6YXvIh0lr58hGRgDnl6AtjNrSbrPNW4kvWH2pNKakFzx yb9Q== MIME-Version: 1.0 References: <1555502021.4884.1.camel@med.uni-goettingen.de> <1555505779.4884.4.camel@med.uni-goettingen.de> <1555510321.4884.7.camel@med.uni-goettingen.de> <1555590011.12545.3.camel@med.uni-goettingen.de> <30c3be07-433d-b945-40de-7b9a02f78789@redhat.com> <917e49da-bc4f-80a8-3399-30fff4a573f0@redhat.com> In-Reply-To: <917e49da-bc4f-80a8-3399-30fff4a573f0@redhat.com> From: Richard Biener Date: Thu, 25 Apr 2019 12:39:00 -0000 Message-ID: Subject: Re: C provenance semantics proposal To: Jeff Law Cc: "Uecker, Martin" , "Peter.Sewell@cl.cam.ac.uk" , "gcc@gcc.gnu.org" , "cl-c-memory-object-model@lists.cam.ac.uk" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00249.txt.bz2 On Wed, Apr 24, 2019 at 8:41 PM Jeff Law wrote: > > On 4/24/19 4:19 AM, Richard Biener wrote: > > On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote: > >> > >> On 4/18/19 6:20 AM, Uecker, Martin wrote: > >>> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: > >>>> On Thu, 18 Apr 2019 at 10:32, Richard Biener wrote: > >>> > >>> > >>>> An equality test of two pointers, on the other hand, doesn't necessarily > >>>> mean that they are interchangeable. I don't see any good way to > >>>> avoid that in a provenance semantics, where a one-past > >>>> pointer might sometimes compare equal to a pointer to an > >>>> adjacent object but be illegal for accessing it. > >>> > >>> As I see it, there are essentially four options: > >>> > >>> 1.) Compilers do not use conditional equivalences for > >>> optimizations of pointers (or only when additional > >>> conditions apply which make it safe) > >> I know this will hit DOM and CSE. I wouldn't be surprised if it touches > >> VRP as well, maybe PTA. It seems simple enough though :-) > > > > Also touches fundamental PHI-OPT transforms like > > > > if (a == b) > > ... > > > > # c = PHI > > > > where we'd lose eliding such a conditional. IMHO that's bad > > and very undesirable. > But if we only suppress this optimization for pointers is it that terrible? I've at least seen a lot of cases with c = PHI for null pointer checks. It's just we're going to chase a lot of cases down even knowing RTL will fuck up later big times. > > > >>> > >>> 3.) We make comparison have the side effect that > >>> afterwards any of the two pointers could have any > >>> of the two provenances. (with disambiguitation > >>> similar to what we have for casts). > >> This could have some interesting effects on PTA. Richi? > > > > I played with this and doing this in an incomplete way like > > just handling > > > > if (a == b) > > > > as two-way assignment during constraint building is possible. > > But that's not enough of course since every call is implicitely > > producing equivalences between everything [escaped] ... > > which makes points-to degrade to a point where it is useless. > But the calls aren't generating conditional equivalences. I must be > missing something here. if (compare_a_and_b (a, b)) ... yes, they are not creating conditional equivalences that can be propagated out (w/o IPA info). But we compute points-to early, then inline (exposing the propagation opportunity), preserving the points-to result. > You're the expert in this space, so if you say > it totally degrades PTA, then it's a non-starter. Well, it's possible to fix all testcases that get thrown to us but what I have difficulties with is designing a way to follow the proposed standard. Btw, I've tried the trivial points-to patch for conditionals only and even that regressed points-to testcases. > > > > So I think we need a working scheme where points-to doesn't > > degrade from equivalencies being computed and the compiler > > being free to introduce equivalences as well as copy-propagate > > those. > > > > Honestly I can't come up with a working solution to this > > problem. > > > >> > >>> > >>> 4.) Compilers make sure that exposed objects never > >>> are allocated next to each other (as Jens proposed). > >> Ugh. Not sure how you enforce that. Consider that the compiler may > >> ultimately have no control over layout of data in static storage. > > > > Make everything 1 byte larger. > Not a bad idea. I suspect the embedded folks would go bananas though. Maybe, but those folks are also using -fno-strict-aliasing ... Anyhow, my issue is that I don't see a clean design that would follow the proposed standard wording (even our current desired implementation behavior btw!) and not degrade simple testcases :/ Richard. > jeff >