This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH 0/5] arch: atomic rework
- From: "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Linus Torvalds <torvalds at linux-foundation dot org>, Richard Biener <richard dot guenther at gmail dot com>, Torvald Riegel <triegel at redhat dot com>, Will Deacon <will dot deacon at arm dot com>, Peter Zijlstra <peterz at infradead dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, David Howells <dhowells at redhat dot com>, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, "akpm at linux-foundation dot org" <akpm at linux-foundation dot org>, "mingo at kernel dot org" <mingo at kernel dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 24 Feb 2014 09:57:11 -0800
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <CA+55aFz9=RQoMO2ipyZgNPNzWGVXi_R9Ar5=o9VBWwXzDDz6jg at mail dot gmail dot com> <20140223003933 dot GQ4250 at linux dot vnet dot ibm dot com> <CA+55aFyjzR_Ga_HOKnBXpKYbuesqovj1-sFTVisD9UwA6JuJtw at mail dot gmail dot com> <20140223063426 dot GT4250 at linux dot vnet dot ibm dot com> <CA+55aFxMJvaQhoEwqgN=XA6gDOdZwoZQHdcAnB-FhAri_hK-6Q at mail dot gmail dot com> <CA+55aFw5tdjmNyHCdcyZ8NPpd1wCgOjLRzstRhp0Njs9azpi8Q at mail dot gmail dot com> <CAFiYyc08cusFTsydD2C4rEZB-k38NnorzEXzKvqab0m3R+qn8w at mail dot gmail dot com> <CA+55aFyYtMm1_UsPVw8mi7o2iH_--1wLvxPUt5Z9mAEOGMgXdQ at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1402241745100 dot 7694 at wotan dot suse dot de> <20140224172856 dot GP8264 at linux dot vnet dot ibm dot com>
- Reply-to: paulmck at linux dot vnet dot ibm dot com
On Mon, Feb 24, 2014 at 09:28:56AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 24, 2014 at 05:55:50PM +0100, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 24 Feb 2014, Linus Torvalds wrote:
> >
> > > > To me that reads like
> > > >
> > > > int i;
> > > > int *q = &i;
> > > > int **p = &q;
> > > >
> > > > atomic_XXX (p, CONSUME);
> > > >
> > > > orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they
> > > > want to say that it orders against aliased storage - but then go further
> > > > and include "indirectly through a chain of pointers"?! Thus an
> > > > atomic read of a int * orders against any 'int' memory operation but
> > > > not against 'float' memory operations?
> > >
> > > No, it's not about type at all, and the "chain of pointers" can be
> > > much more complex than that, since the "int *" can point to within an
> > > object that contains other things than just that "int" (the "int" can
> > > be part of a structure that then has pointers to other structures
> > > etc).
> >
> > So, let me try to poke holes into your definition or increase my
> > understanding :) . You said "chain of pointers"(dereferences I assume),
> > e.g. if p is result of consume load, then access to
> > p->here->there->next->prev->stuff is supposed to be ordered with that load
> > (or only when that last load/store itself is also an atomic load or
> > store?).
> >
> > So, what happens if the pointer deref chain is partly hidden in some
> > functions:
> >
> > A * adjustptr (B *ptr) { return &ptr->here->there->next; }
> > B * p = atomic_XXX (&somewhere, consume);
> > adjustptr(p)->prev->stuff = bla;
> >
> > As far as I understood you, this whole ptrderef chain business would be
> > only an optimization opportunity, right? So if the compiler can't be sure
> > how p is actually used (as in my function-using case, assume adjustptr is
> > defined in another unit), then the consume load would simply be
> > transformed into an acquire (or whatever, with some barrier I mean)? Only
> > _if_ the compiler sees all obvious uses of p (indirectly through pointer
> > derefs) can it, yeah, do what with the consume load?
>
> Good point, I left that out of my list. Adding it:
>
> 13. By default, pointer chains do not propagate into or out of functions.
> In implementations having attributes, a [[carries_dependency]]
> may be used to mark a function argument or return as passing
> a pointer chain into or out of that function.
>
> If a function does not contain memory_order_consume loads and
> also does not contain [[carries_dependency]] attributes, then
> that function may be compiled using any desired dependency-breaking
> optimizations.
>
> The ordering effects are implementation defined when a given
> pointer chain passes into or out of a function through a parameter
> or return not marked with a [[carries_dependency]] attributed.
>
> Note that this last paragraph differs from the current standard, which
> would require ordering regardless.
And there is also kill_dependency(), which needs to be added to the list
in #8 of operators that take a chained pointer and return something that
is not a chained pointer.
Thanx, Paul