From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130413 invoked by alias); 3 Jul 2019 15:09:52 -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 129973 invoked by uid 89); 3 Jul 2019 15:09:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=claiming 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 15:09:49 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x63EwGuX023113 for ; Wed, 3 Jul 2019 11:09:47 -0400 Received: from e12.ny.us.ibm.com (e12.ny.us.ibm.com [129.33.205.202]) by mx0a-001b2d01.pphosted.com with ESMTP id 2tgvsq5pnr-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 03 Jul 2019 11:09:47 -0400 Received: from localhost by e12.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Jul 2019 16:09:45 +0100 Received: from b01cxnp23032.gho.pok.ibm.com (9.57.198.27) by e12.ny.us.ibm.com (146.89.104.199) 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:09:43 +0100 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x63F9h7443057598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Jul 2019 15:09:43 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F375AB2064; Wed, 3 Jul 2019 15:09:42 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C70A0B205F; Wed, 3 Jul 2019 15:09:42 +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:09:42 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 2E02816C5DE8; Wed, 3 Jul 2019 08:09:44 -0700 (PDT) Date: Wed, 03 Jul 2019 15:09:00 -0000 From: "Paul E. McKenney" To: Richard Biener Cc: gcc@gcc.gnu.org, Jason Merrill , Akshat Garg , Ramana Radhakrishnan Subject: Re: Doubts regarding the _Dependent_ptr keyword Reply-To: paulmck@linux.ibm.com References: <20190619164145.GJ26519@linux.ibm.com> <20190620140600.GA15142@linux.ibm.com> <20190702005935.GB26519@linux.ibm.com> <06C4A878-BF18-4864-933B-52A1391A8055@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06C4A878-BF18-4864-933B-52A1391A8055@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) x-cbid: 19070315-0060-0000-0000-000003588379 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.01226887; UDB=6.00645941; IPR=6.01008115; MB=3.00027569; MTD=3.00000008; XFM=3.00000015; UTC=2019-07-03 15:09:45 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19070315-0061-0000-0000-00004A0028E6 Message-Id: <20190703150944.GA22612@linux.ibm.com> X-SW-Source: 2019-07/txt/msg00035.txt.bz2 On Tue, Jul 02, 2019 at 07:53:20PM +0200, Richard Biener wrote: > On July 2, 2019 5:36:08 PM GMT+02:00, Jason Merrill wrote: > >On Mon, Jul 1, 2019 at 8:59 PM Paul E. McKenney > >wrote: > >> > >> On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote: > >> > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg > >wrote: > >> > > >> > > On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan < > >> > > ramana.gcc@googlemail.com> wrote: > >> > > > >> > >> On Tue, Jun 25, 2019 at 11:03 AM Akshat Garg > >wrote: > >> > >> > > >> > >> > As we have some working front-end code for _Dependent_ptr, > >What should > >> > >> we do next? What I understand, we can start adding the library > >for > >> > >> dependent_ptr and its functions for C corresponding to the ones > >we created > >> > >> as C++ template library. Then, after that, we can move on to > >generating the > >> > >> assembly code part. > >> > >> > > >> > >> > >> > >> > >> > >> I think the next step is figuring out how to model the Dependent > >> > >> pointer information in the IR and figuring out what > >optimizations to > >> > >> allow or not with that information. At this point , I suspect we > >need > >> > >> a plan on record and have the conversation upstream on the > >lists. > >> > >> > >> > >> I think we need to put down a plan on record. > >> > >> > >> > >> Ramana > >> > > > >> > > [CCing gcc mailing list] > >> > > > >> > > So, shall I start looking over the pointer optimizations only and > >see what > >> > > information we may be needed on the same examples in the IR > >itself? > >> > > > >> > > - Akshat > >> > > > >> > I have coded an example where equality comparison kills dependency > >from the > >> > document P0190R4 as shown below : > >> > > >> > 1. struct rcutest rt = {1, 2, 3}; > >> > 2. void thread0 () > >> > 3. { > >> > 4. rt.a = -42; > >> > 5. rt.b = -43; > >> > 6. rt.c = -44; > >> > 7. rcu_assign_pointer(gp, &rt); > >> > 8. } > >> > 9. > >> > 10. void thread1 () > >> > 11. { > >> > 12. int i = -1; > >> > 13. int j = -1; > >> > 14. _Dependent_ptr struct rcutest *p; > >> > 15. > >> > 16. p = rcu_dereference(gp); > >> > 17. j = p->a; > >> > 18. if (p == &rt) > >> > 19. i = p->b; /*Dependency breaking point*/ > >> > 20. else if(p) > >> > 21. i = p->c; > >> > 22. assert(i<0); > >> > 23. assert(j<0); > >> > 24. } > >> > The gimple unoptimized code produced for lines 17-24 is shown below > >> > > >> > 1. if (p_16 == &rt) > >> > 2. goto ; [INV] > >> > 3. else > >> > 4. goto ; [INV] > >> > 5. > >> > 6. : > >> > 7. i_19 = p_16->b; > >> > 8. goto ; [INV] > >> > 9. > >> > 10. : > >> > 11. if (p_16 != 0B) > >> > 12. goto ; [INV] > >> > 13. else > >> > 14. goto ; [INV] > >> > 15. > >> > 16. : > >> > 17. i_18 = p_16->c; > >> > 18. > >> > 19. : > >> > 20. # i_7 = PHI > >> > 21. _3 = i_7 < 0; > >> > 22. _4 = (int) _3; > >> > 23. assert (_4); > >> > 24. _5 = j_17 < 0; > >> > 25. _6 = (int) _5; > >> > 26. assert (_6); > >> > 27. return; > >> > > >> > The optimized code after -O1 is applied for the same lines is hown > >below : > >> > > >> > 1. if (_2 == &rt) > >> > 2. goto ; [30.00%] > >> > 3. else > >> > 4. goto ; [70.00%] > >> > 5. > >> > 6. [local count: 322122547]: > >> > 7. i_12 = rt.b; > >> > 8. goto ; [100.00%] > >> > 9. > >> > 10. [local count: 751619277]: > >> > 11. if (_1 != 0) > >> > 12. goto ; [50.00%] > >> > 13. else > >> > 14. goto ; [50.00%] > >> > 15. > >> > 16. [local count: 375809638]: > >> > 17. i_11 = MEM[(dependent_ptr struct rcutest *)_2].c; > >> > 18. > >> > 19. [local count: 1073741824]: > >> > 20. # i_7 = PHI > >> > 21. _3 = i_7 < 0; > >> > 22. _4 = (int) _3; > >> > 23. assert (_4); > >> > 24. _5 = j_10 < 0; > >> > 25. _6 = (int) _5; > >> > 26. assert (_6); > >> > 27. return; > >> > >> Good show on tracing this through! > >> > >> > Statement 19 in the program gets converted from i_19 = p_16->b; in > >line 7 > >> > in unoptimized code to i_12 = rt.b; in line 7 in optimized code > >which > >> > breaks the dependency chain. We need to figure out the pass that > >does that > >> > and put some handling code in there for the _dependent_ptr > >qualified > >> > pointers. > > Wtf should this be for? A type qualifier is certainly not going to work. I might be wrong, but I don't believe that Akshat is claiming that this is already a complete solution. But please tell us more. Given what Akshat is trying to do, what else is missing or otherwise in need of fixing? Thanx, Paul > Richard. > > > Passing simply -fipa-pure-const, > >-fguess-branch-probability or > >> > any other option alone does not produce the optimized code that > >breaks the > >> > dependency. But applying -O1, i.e., allowing all the optimizations > >does so. > >> > As passes are applied in a certain order, we need to figure out up > >to what > >> > passes, the code remains same and after what pass the dependency > >does not > >> > holds. So, we need to check the translated code after every pass. > >> > > >> > 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. > >> > >> I don't know of a better plan. > >> > >> My usual question... Is there some way to script the checking of the > >> translated code at the end of each pass? > > > >The usual way to check the output of an optimization pass is by > >dumping the intermediate code at that point and matching the dump > >against a regexp, as in the tree-ssa directories in the testsuite. > >-fdump-tree-all will dump after all the gimple optimization passes, > >and you can look through them until you find the breakage. > > > >Jason >