From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90313 invoked by alias); 4 Jul 2019 17:40:23 -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 90305 invoked by uid 89); 4 Jul 2019 17:40:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy= 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; Thu, 04 Jul 2019 17:40:21 +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 x64HbMNe084886 for ; Thu, 4 Jul 2019 13:40:20 -0400 Received: from e11.ny.us.ibm.com (e11.ny.us.ibm.com [129.33.205.201]) by mx0b-001b2d01.pphosted.com with ESMTP id 2thmeftxx8-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 04 Jul 2019 13:40:19 -0400 Received: from localhost by e11.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 4 Jul 2019 18:40:19 +0100 Received: from b01cxnp23033.gho.pok.ibm.com (9.57.198.28) by e11.ny.us.ibm.com (146.89.104.198) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 4 Jul 2019 18:40:15 +0100 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x64HeF3E52691210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Jul 2019 17:40:15 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 054EEB2066; Thu, 4 Jul 2019 17:40:15 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C63A9B205F; Thu, 4 Jul 2019 17:40:14 +0000 (GMT) Received: from paulmck-ThinkPad-W541 (unknown [9.80.225.224]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 4 Jul 2019 17:40:14 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 80CEC16C8EB0; Thu, 4 Jul 2019 10:40:15 -0700 (PDT) Date: Thu, 04 Jul 2019 17:40: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> <20190703163355.GQ26519@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: 19070417-2213-0000-0000-000003A961AD X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00011378; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000286; SDB=6.01227405; UDB=6.00646258; IPR=6.01008642; MB=3.00027587; MTD=3.00000008; XFM=3.00000015; UTC=2019-07-04 17:40:17 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19070417-2214-0000-0000-00005F1B997F Message-Id: <20190704174015.GJ26519@linux.ibm.com> X-SW-Source: 2019-07/txt/msg00045.txt.bz2 On Thu, Jul 04, 2019 at 01:00:18PM +0200, Richard Biener wrote: > On Wed, Jul 3, 2019 at 6:33 PM Paul E. McKenney wrote: > > > > 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? > > Browsed through that resources, so yes. So the important thing > is that data dependences in the source are not to be removed or > replaced by control dependences because that enables out-of-order > execution on the CPU (or by the compiler). This is only needed > for data typed with the _Dependent_ptr qualifier. > > I think fully guaranteeing this is hard (besides when you use > volatile), we have the very same issue when dealing with > pointer provenance rules, known for years and not fixed > (and I don't see a good way to fix these issues without > sacrifying performance everywhere). > > Good luck ;) Thank you, we will need it! ;-) > Maybe performance isn't so much of an issue for _Dependent_ptr > (compared to when all pointers are affected). Here is hoping! Thanx, Paul > Richard. > > > > > 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 > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > >