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 <paul...@linux.ibm.com>
> 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 <paul...@linux.ibm.com>
> > 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.
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
> > > > >
> > > >
> > >
> >
> >
