public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ramana Radhakrishnan <ramana.gcc@googlemail.com>
To: Akshat Garg <xkspr7@gmail.com>
Cc: Paul McKenney <paulmck@linux.ibm.com>,
	gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Doubts regarding the _Dependent_ptr keyword
Date: Tue, 02 Jul 2019 10:22:00 -0000	[thread overview]
Message-ID: <CAJA7tRZ4k_5nYYhiffwVGk=wwXOmqB2vqHv-q8dwZFmhw1HPxg@mail.gmail.com> (raw)
In-Reply-To: <CAMEQ7Yy_gV8UkCK52ppZ9MPjCGzzvGGd29Y3WGTNOfP-56sRUw@mail.gmail.com>

On Tue, Jul 2, 2019 at 1:29 AM Akshat Garg <xkspr7@gmail.com> wrote:
>
> On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg <xkspr7@gmail.com> wrote:
>>
>> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan <ramana.gcc@googlemail.com> wrote:
>>>
>> [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 <bb 3>; [INV]
> 3.   else
> 4.    goto <bb 4>; [INV]
> 5.
> 6.  <bb 3> :
> 7.  i_19 = p_16->b;
> 8.  goto <bb 6>; [INV]
> 9.
> 10.  <bb 4> :
> 11.  if (p_16 != 0B)
> 12.    goto <bb 5>; [INV]
> 13.  else
> 14.    goto <bb 6>; [INV]
> 15.
> 16.  <bb 5> :
> 17.  i_18 = p_16->c;
> 18.
> 19.  <bb 6> :
> 20.  # i_7 = PHI <i_19(3), i_8(4), i_18(5)>
> 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 <bb 3>; [30.00%]
> 3. else
> 4.    goto <bb 4>; [70.00%]
> 5.
> 6.  <bb 3> [local count: 322122547]:
> 7.   i_12 = rt.b;
> 8.   goto <bb 6>; [100.00%]
> 9.
> 10.  <bb 4> [local count: 751619277]:
> 11.   if (_1 != 0)
> 12.   goto <bb 5>; [50.00%]
> 13.   else
> 14.    goto <bb 6>; [50.00%]
> 15.
> 16.  <bb 5> [local count: 375809638]:
> 17.   i_11 = MEM[(dependent_ptr struct rcutest *)_2].c;
> 18.
> 19.   <bb 6> [local count: 1073741824]:
> 20.  # i_7 = PHI <i_12(3), i_11(5), -1(4)>
> 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;
>
> 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. 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 upto 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.
>

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 kill the dependencies at somepoint.
>
> -Akshat

  parent reply	other threads:[~2019-07-02 10:22 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMEQ7Yw5mV+zoDV-kmOnWoy4+_CiDeUyJmipkkrTGhxninp3Hw@mail.gmail.com>
     [not found] ` <20190617023256.GJ26519@linux.ibm.com>
     [not found]   ` <CAMEQ7Yxp-o+4dPd_o=eaPYqpV1n7KfqMS_Un1U1n9-ut_HK_uw@mail.gmail.com>
     [not found]     ` <20190618211927.GY26519@linux.ibm.com>
     [not found]       ` <CAJA7tRYJPaFuvR+bC40kGdKOLVTHEFnD1SkBqF6oUcpv-bLMbw@mail.gmail.com>
     [not found]         ` <CAMEQ7YyN72aMAEsuKW4GQua_Vyi8Wd6F6BKcTo8dS_JcLm2TvQ@mail.gmail.com>
     [not found]           ` <CAMEQ7YxT4mwNvgr_iqxKAJE=yeuOmhcNkHL1ET-84hwv9uMwdQ@mail.gmail.com>
     [not found]             ` <CAJA7tRZVhVtabJLgWJ3BK3HhR2pf+X0fiG+sF=y2Y=PkWg8eTQ@mail.gmail.com>
     [not found]               ` <CAMEQ7YyLp0YymRiYD4O_1A=YswbbDBh0gQz9kGtw4t8mfvU4Jg@mail.gmail.com>
     [not found]                 ` <20190619164145.GJ26519@linux.ibm.com>
     [not found]                   ` <20190620140600.GA15142@linux.ibm.com>
     [not found]                     ` <CAMEQ7Yx=dg0TWcXKA8eZk=RCN+az116Y9whKGQSB3fRVZwbvQw@mail.gmail.com>
     [not found]                       ` <CAJA7tRbj6eoOj_fr+Nnm1rS=kdc0jPxkb77AoPCFrJEaaPsCSA@mail.gmail.com>
2019-06-25 16:20                         ` Akshat Garg
2019-07-02  0:29                           ` Akshat Garg
2019-07-02  0:59                             ` Paul E. McKenney
2019-07-02  1:42                               ` nick
2019-07-02 15:36                               ` Jason Merrill
2019-07-02 17:53                                 ` Richard Biener
2019-07-03 15:09                                   ` Paul E. McKenney
2019-07-02 19:37                                 ` Akshat Garg
2019-07-17 10:54                                 ` Akshat Garg
2019-07-22  0:27                                   ` Akshat Garg
2019-07-22  8:41                                     ` Richard Biener
2019-07-22  8:54                                       ` Akshat Garg
2019-07-22  9:46                                         ` Richard Biener
2019-07-23 20:11                                           ` Akshat Garg
2019-07-23 20:50                                             ` Akshat Garg
2019-07-02 10:22                             ` Ramana Radhakrishnan [this message]
2019-07-02 10:39                               ` Akshat Garg
2019-07-02 11:01                                 ` Ramana Radhakrishnan
2019-07-02 12:38                                   ` Paul E. McKenney
2019-07-02 13:16                                     ` Ramana Radhakrishnan
2019-07-02 15:09                                       ` Paul E. McKenney
2019-07-02 19:09                                         ` Akshat Garg
2019-07-03 15:16                                           ` Paul E. McKenney
2019-07-03 15:48                                             ` Richard Biener
2019-07-03 16:34                                               ` Paul E. McKenney
2019-07-04 11:00                                                 ` Richard Biener
2019-07-04 17:40                                                   ` Paul E. McKenney
2019-07-04 18:09                                                     ` Jakub Jelinek
2019-07-04 23:08                                                       ` Akshat Garg
2019-07-05 11:20                                                         ` Richard Biener
2019-07-05 15:38                                                           ` Akshat Garg
     [not found]                                                         ` <20190705014806.GM26519@linux.ibm.com>
     [not found]                                                           ` <CAMEQ7YyrjkGVhnLUCXMrbyicPkRZkpZvH_3KQ56cNh_6+Tr4iQ@mail.gmail.com>
     [not found]                                                             ` <CAMEQ7YzOqU68kQN99g_zhwJUkNaJa9q_Dv9pue+4NFK4rYubFg@mail.gmail.com>
     [not found]                                                               ` <20190707141928.GE26519@linux.ibm.com>
     [not found]                                                                 ` <CAMEQ7YyuzvN_OzU4oMJGaFMBpnQwkCt4=ZTo-AmSmvsr2dBOMw@mail.gmail.com>
2019-07-07 21:44                                                                   ` Akshat Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJA7tRZ4k_5nYYhiffwVGk=wwXOmqB2vqHv-q8dwZFmhw1HPxg@mail.gmail.com' \
    --to=ramana.gcc@googlemail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=paulmck@linux.ibm.com \
    --cc=xkspr7@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).