public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Akshat Garg <xkspr7@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>,
	Richard Biener <richard.guenther@gmail.com>,
		Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
	gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Doubts regarding the _Dependent_ptr keyword
Date: Thu, 04 Jul 2019 23:08:00 -0000	[thread overview]
Message-ID: <CAMEQ7Yx1JtdAiKJpe6_cd7RJ0J7KqP_+HCB=O=SP+SuJvvWUVA@mail.gmail.com> (raw)
In-Reply-To: <20190704180939.GI815@tucnak>

On Thu, Jul 4, 2019 at 11:39 PM Jakub Jelinek <jakub@redhat.com> wrote:

> On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote:
> > > 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!  ;-)
>
> Well, luck probably isn't all you need, you'll need some way to represent
> those dependencies in the IL (both GIMPLE and RTL) that would ensure that
> they aren't optimized away, because just hoping that optimization don't
> mess
> that up or just patching a few optimizations you discover first isn't going
> to be very reliable.  Say don't rewrite those into SSA form and represent
> them close to how volatile ptrs are handled at least for the beginning, and
> if there are safe optimizations special case those, rather than allowing
> all
> optimizations on those and hope it will work out.
>
>         Jakub
>
I don't understand this statement completely "Say don't rewrite those into
SSA form and represent them close to how volatile ptrs are handled at least
for the beginning, and if there are safe optimizations special case those,
rather than allowing all optimizations on those and hope it will work
out.".
Are you saying that we should try to represent dependent ptrs as volatile
ptrs for some places?  We should figure out all the places where a check
for volatile ptrs happens and we check for dependent ptrs there also and
see if we can allow the optimization or not.
Am I getting you correctly, please tell?

-Akshat

  reply	other threads:[~2019-07-04 23:08 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
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 [this message]
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='CAMEQ7Yx1JtdAiKJpe6_cd7RJ0J7KqP_+HCB=O=SP+SuJvvWUVA@mail.gmail.com' \
    --to=xkspr7@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=paulmck@linux.ibm.com \
    --cc=ramana.gcc@googlemail.com \
    --cc=richard.guenther@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).