From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11830 invoked by alias); 3 Jul 2019 15:16:10 -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 11819 invoked by uid 89); 3 Jul 2019 15:16:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=technique X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Jul 2019 15:16:08 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x63FElsJ084545 for ; Wed, 3 Jul 2019 11:16:06 -0400 Received: from e14.ny.us.ibm.com (e14.ny.us.ibm.com [129.33.205.204]) by mx0b-001b2d01.pphosted.com with ESMTP id 2tgvy5d56j-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 03 Jul 2019 11:16:03 -0400 Received: from localhost by e14.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Jul 2019 16:14:59 +0100 Received: from b01cxnp22036.gho.pok.ibm.com (9.57.198.26) by e14.ny.us.ibm.com (146.89.104.201) 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 16:14:58 +0100 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x63FEvwl24248578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Jul 2019 15:14:57 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ACD00B205F; Wed, 3 Jul 2019 15:14:57 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 91400B2064; Wed, 3 Jul 2019 15:14:57 +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 15:14:57 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id EEC6616C5DE8; Wed, 3 Jul 2019 08:14:58 -0700 (PDT) Date: Wed, 03 Jul 2019 15:16:00 -0000 From: "Paul E. McKenney" To: Akshat Garg Cc: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) x-cbid: 19070315-0052-0000-0000-000003D9E97A 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.01226889; UDB=6.00645942; IPR=6.01008117; MB=3.00027569; MTD=3.00000008; XFM=3.00000015; UTC=2019-07-03 15:14:59 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19070315-0053-0000-0000-0000618DEA16 Message-Id: <20190703151458.GM26519@linux.ibm.com> X-SW-Source: 2019-07/txt/msg00036.txt.bz2 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. 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 > > > > > > > > > > > > > > > >