From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70965 invoked by alias); 2 Jul 2019 10:22:58 -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 70957 invoked by uid 89); 2 Jul 2019 10:22:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:bC40kGd, H*f:4dPd_o, H*f:sk:eaPYqpV, H*f:CAMEQ7Yw5mV X-HELO: mail-vs1-f54.google.com Received: from mail-vs1-f54.google.com (HELO mail-vs1-f54.google.com) (209.85.217.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jul 2019 10:22:56 +0000 Received: by mail-vs1-f54.google.com with SMTP id k9so10873962vso.5 for ; Tue, 02 Jul 2019 03:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IvRsZ/oX/QRRYeYw2OdM8Kv6ccaKVCKrsvKnDK6vVUc=; b=py/2rnQVxqo8pZxGbeCaZc2CjdcKa+agL9T0h7qgYZKjoCzFnXiibsVYne34rruf+/ 58ztnb517mJujt7/U11eNj5FHaFE3igsUq58r6+UsB6ka6+OMNORkjukT+7r37/7yre3 51MvWS3QSaM/J03nbqYun+KSRoRKeUTTUvkHGjyvpTJbtsQ0hJwonnjt7QMQ5CZbs1p4 hAEpDYYv/Jg+TvXenfPumQXS3xghr/XH5lIIf6yR3pWL3DGpqPoXu2m/DEPBuTofVjFA dTedwcGI2qeFynJPVxIsZapD1937a4gxCZi4cbV/gOOXbwAL0J7srXgZ2FRRBtDO/gfg 5/tg== MIME-Version: 1.0 References: <20190617023256.GJ26519@linux.ibm.com> <20190618211927.GY26519@linux.ibm.com> <20190619164145.GJ26519@linux.ibm.com> <20190620140600.GA15142@linux.ibm.com> In-Reply-To: From: Ramana Radhakrishnan Date: Tue, 02 Jul 2019 10:22:00 -0000 Message-ID: Subject: Re: Doubts regarding the _Dependent_ptr keyword To: Akshat Garg Cc: Paul McKenney , gcc mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00020.txt.bz2 On Tue, Jul 2, 2019 at 1:29 AM 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 wrote: >>> >> [CCing gcc mailing list] >> >> So, shall I start looking over the pointer optimizations only and see wh= at 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 t= he document P0190R4 as shown below : > > 1. struct rcutest rt =3D {1, 2, 3}; > 2. void thread0 () > 3. { > 4. rt.a =3D -42; > 5. rt.b =3D -43; > 6. rt.c =3D -44; > 7. rcu_assign_pointer(gp, &rt); > 8. } > 9. > 10. void thread1 () > 11. { > 12. int i =3D -1; > 13. int j =3D -1; > 14. _Dependent_ptr struct rcutest *p; > 15. > 16. p =3D rcu_dereference(gp); > 17. j =3D p->a; > 18. if (p =3D=3D &rt) > 19. i =3D p->b; /*Dependency breaking point*/ > 20. else if(p) > 21. i =3D 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 =3D=3D &rt) > 2. goto ; [INV] > 3. else > 4. goto ; [INV] > 5. > 6. : > 7. i_19 =3D p_16->b; > 8. goto ; [INV] > 9. > 10. : > 11. if (p_16 !=3D 0B) > 12. goto ; [INV] > 13. else > 14. goto ; [INV] > 15. > 16. : > 17. i_18 =3D p_16->c; > 18. > 19. : > 20. # i_7 =3D PHI > 21. _3 =3D i_7 < 0; > 22. _4 =3D (int) _3; > 23. assert (_4); > 24. _5 =3D j_17 < 0; > 25. _6 =3D (int) _5; > 26. assert (_6); > 27. return; > > The optimized code after -O1 is applied for the same lines is hown below : > > 1. if (_2 =3D=3D &rt) > 2. goto ; [30.00%] > 3. else > 4. goto ; [70.00%] > 5. > 6. [local count: 322122547]: > 7. i_12 =3D rt.b; > 8. goto ; [100.00%] > 9. > 10. [local count: 751619277]: > 11. if (_1 !=3D 0) > 12. goto ; [50.00%] > 13. else > 14. goto ; [50.00%] > 15. > 16. [local count: 375809638]: > 17. i_11 =3D MEM[(dependent_ptr struct rcutest *)_2].c; > 18. > 19. [local count: 1073741824]: > 20. # i_7 =3D PHI > 21. _3 =3D i_7 < 0; > 22. _4 =3D (int) _3; > 23. assert (_4); > 24. _5 =3D j_10 < 0; > 25. _6 =3D (int) _5; > 26. assert (_6); > 27. return; > > Statement 19 in the program gets converted from i_19 =3D p_16->b; in lin= e 7 in unoptimized code to i_12 =3D 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 point= ers. Passing simply -fipa-pure-const, -fguess-branch-probability or any oth= er option alone does not produce the optimized code that breaks the depende= ncy. But applying -O1, i.e., allowing all the optimizations does so. As pas= ses are applied in a certain order, we need to figure out upto what passes,= the code remains same and after what pass the dependency does not holds. S= o, we need to check the translated code after every pass. > It's worth figuring out what passes are doing this - however the worry I have is that every pass now needs to be handling this case with respect to pointer attributes. Is there some place that you are storing said information and what is the transitive nature of assignments with these attributes ? regards 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 k= ill the dependencies at somepoint. > > -Akshat