Doubts regarding the _Dependent_ptr keyword

[Richard Biener]

On July 3, 2019 5:14:58 PM GMT+02:00, "Paul E. McKenney" <paulmck@linux.ibm.com> wrote:
>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
><paulmck@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
><paulmck@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.

With this example can you quickly summarize what kind of guarantees _Dependent_ptr gives and how a compiler
Could possibly break those? 

Richard. 

>
>							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
>> > > > >
>> > > >
>> > >
>> >
>> >