From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42718 invoked by alias); 3 Jul 2019 16:34:01 -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 42710 invoked by uid 89); 3 Jul 2019 16:34:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=H*i:sk:3C6A1B8, H*f:sk:3C6A1B8, 56pm, 56PM X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Jul 2019 16:33:59 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x63GXDWO079500 for ; Wed, 3 Jul 2019 12:33:58 -0400 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0a-001b2d01.pphosted.com with ESMTP id 2tgxtm2pu7-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 03 Jul 2019 12:33:58 -0400 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Jul 2019 17:33:56 +0100 Received: from b01cxnp22034.gho.pok.ibm.com (9.57.198.24) by e13.ny.us.ibm.com (146.89.104.200) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 3 Jul 2019 17:33:55 +0100 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x63GXsx143188576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Jul 2019 16:33:54 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 28912B205F; Wed, 3 Jul 2019 16:33:54 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EF096B2065; Wed, 3 Jul 2019 16:33:53 +0000 (GMT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.26]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 3 Jul 2019 16:33:53 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 696E016C0A9F; Wed, 3 Jul 2019 09:33:55 -0700 (PDT) Date: Wed, 03 Jul 2019 16:34:00 -0000 From: "Paul E. McKenney" To: Richard Biener Cc: Akshat Garg , Ramana Radhakrishnan , gcc mailing list Subject: Re: Doubts regarding the _Dependent_ptr keyword Reply-To: paulmck@linux.ibm.com References: <20190702123809.GM26519@linux.ibm.com> <20190702150931.GR26519@linux.ibm.com> <20190703151458.GM26519@linux.ibm.com> <3C6A1B8D-33B6-4CC3-B88C-3A547601D4AD@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6A1B8D-33B6-4CC3-B88C-3A547601D4AD@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) x-cbid: 19070316-0064-0000-0000-000003F6B79E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00011372; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000286; SDB=6.01226916; UDB=6.00645957; IPR=6.01008143; MB=3.00027570; MTD=3.00000008; XFM=3.00000015; UTC=2019-07-03 16:33:56 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19070316-0065-0000-0000-00003E205B2D Message-Id: <20190703163355.GQ26519@linux.ibm.com> X-SW-Source: 2019-07/txt/msg00038.txt.bz2 On Wed, Jul 03, 2019 at 05:47:56PM +0200, Richard Biener wrote: > On July 3, 2019 5:14:58 PM GMT+02:00, "Paul E. McKenney" wrote: > >On Wed, Jul 03, 2019 at 12:39:41AM +0530, Akshat Garg wrote: > >> On Tue, Jul 2, 2019 at 8:40 PM Paul E. McKenney > > > >> wrote: > >> > >> > On Tue, Jul 02, 2019 at 02:15:55PM +0100, Ramana Radhakrishnan > >wrote: > >> > > On Tue, Jul 2, 2019 at 1:38 PM Paul E. McKenney > > > >> > wrote: > >> > > > >> > > > > >> > > > Once a user-created non-dependent pointer is assigned to, it is > >OK to > >> > > > break the dependency. > >> > > > >> > > Ok, that's good. > >> > > > > >> > > > Or am I missing the point here? > >> > > > >> > > I was just trying to make sure we were on the same page. I wonder > >if > >> > > marking this volatile would be sufficient for prototyping. I > >suspect > >> > > we would need another flag somewhere which someone with gimple > >> > > knowledge might be able to help us with. > >> > > >> > I expect that marking it as volatile would do the trick. ;-) > >> > > >> > Thanx, Paul > >> > > >> So, marking this pointer as volatile will not allow the compiler to > >> modify/optimize the statements, the pointer is appearing in. And we > >don't > >> need to push any other code inside any of the passes. Due to this, we > >want > >> to automatically say those dependent pointers are volatile and > >introduce a > >> new flag for this. Am I getting you guys correctly? Kindly, let me > >know? > > > >While I suspect that this might work, it would suppress way more > >optimizations than would be good. For but one example, consider: > > > > _Dependent_ptr int *p; > > > > p = atomic_load_explicit(gp, memory_order_consume); > > a = p->a; > > b = p->b; > > > >If "p" is volatile, then the compiler will be prevented from keeping > >it in a register, which would not make people coding fastpaths at > >all happy. ;-) > > > >Still, use of volatile might be a good technique for prototyping and > >analysis of _Dependent_ptr. > > With this example can you quickly summarize what kind of guarantees _Dependent_ptr gives and how a compiler > Could possibly break those? First I suppose I should fix the bug in the above code. Or one of the bugs, at least. :-/ struct foo { int a; int b; }; _Dependent_ptr struct foo *p; p = atomic_load_explicit(gp, memory_order_consume); a = p->a; b = p->b; And then let me tweak the example a bit. For the first tweak: struct foo { int a; int b; }; struct foo default_foo = { .a = 42, .b = 43 }; int *gp = &default_foo; ... _Dependent_ptr int *p; p = atomic_load_explicit(gp, memory_order_consume); a = p->a; b = p->b; Suppose that the compiler used feedback-driven optimization, and noticed that the value of gp was almost always &default_foo. The compiler might decide to transform the last three lines as follows: p = atomic_load_explicit(gp, memory_order_consume); if (p == &default_foo) { a = default_foo.a; b = default_foo.b; } else { a = p->a; b = p->b; } Now, as long as the value of gp had remained &default_foo for the full duration of execution, no harm done. But suppose the following code was executing concurrently with the above transformed code: struct foo *q; q = malloc(sizeof(*q)); assert(q); q->a = 1729; q->b = 1730; atomic_store_explicit(gp, q, memory_order_release); do_something(); default_foo.a = 1; default_foo.b = 2; atomic_store_explicit(gp, &default_foo, memory_order_release); In this case, if the memory_order_consume() came just after the pointer was reset to &default_foo, it is possible that the transformed code would set "a" to 42 and "b" to 43, which might not be what the guy writing the code wanted to happen. One of the purposes of _Dependent_ptr is to prevent this transformation. This transformation can also happen if the developer's code contained a comparison to &default_foo -- an ARM or PowerPC compiler backend, upon seeing two pointers containing the same bits, would likely consider the two pointers as being interchangeable, and thus might do the dereferences using the copy that was not tagged with the hardware dependencies. There are quite a few other examples. The C++ standards committee working papers shown below go through a number of them, in case the above example is not convincing. Or you could tell me what you would like to see, and I would attempt to find/create a suitable example. Does that help, or am I missing your point? Thanx, Paul http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0098r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0462r1.pdf > Richard. > > > > > Thanx, Paul > > > >> Akshat > >> > >> > > >> > > regards > >> > > Ramana > >> > > > >> > > > > >> > > > Thanx, > >Paul > >> > > > > >> > > > > Ramana > >> > > > > >> > >> > > > > >> > >> > > > > >> > Does this sounds like a workable plan for ? Let me know > >your > >> > thoughts. If this sounds good then, we can do this for all the > >> > optimizations that may kill the dependencies at somepoint. > >> > > > > >> > > >> > > > > >> > -Akshat > >> > > > > > >> > > > > >> > > > >> > > >> > >