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: Torvald Riegel <triegel at redhat dot com>
- To: paulmck at linux dot vnet dot ibm dot com
- Cc: Michael Matz <matz at suse dot de>, Linus Torvalds <torvalds at linux-foundation dot org>, 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: Wed, 26 Feb 2014 14:04:30 +0100
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <CA+55aFwwscSzwTr+xRdirtTx7HzugmMY9HrDe0GBqNhn=AuNVA at mail dot gmail dot com> <20140220083032 dot GN4250 at linux dot vnet dot ibm dot com> <CA+55aFwfx==u7o1NZ66aPbkOgsvGqW3UscGqrQkGuzOkjSpm6Q at mail dot gmail dot com> <20140220181116 dot GT4250 at linux dot vnet dot ibm dot com> <CA+55aFwn9gXWVq_GL=tPPP63vsqs-9QB4ii4s06xqG4UscCV5w at mail dot gmail dot com> <20140220185608 dot GX4250 at linux dot vnet dot ibm dot com> <CA+55aFw4inow5B-JAg-NtZigJ90yDbksddr00RoMKytzDAEa8A at mail dot gmail dot com> <20140220221027 dot GC4250 at linux dot vnet dot ibm dot com> <CA+55aFxp7U67R0PARaUfj94y5dJ8q6_HQ2pnbQ6=JD=XR-bTOw at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1402211847290 dot 7694 at wotan dot suse dot de> <20140221191318 dot GK4250 at linux dot vnet dot ibm dot com>
On Fri, 2014-02-21 at 11:13 -0800, Paul E. McKenney wrote:
> On Fri, Feb 21, 2014 at 07:35:37PM +0100, Michael Matz wrote:
> > Hi,
> >
> > On Thu, 20 Feb 2014, Linus Torvalds wrote:
> >
> > > But I'm pretty sure that any compiler guy must *hate* that current odd
> > > dependency-generation part, and if I was a gcc person, seeing that
> > > bugzilla entry Torvald pointed at, I would personally want to
> > > dismember somebody with a rusty spoon..
> >
> > Yes. Defining dependency chains in the way the standard currently seems
> > to do must come from people not writing compilers. There's simply no
> > sensible way to implement it without being really conservative, because
> > the depchains can contain arbitrary constructs including stores,
> > loads and function calls but must still be observed.
> >
> > And with conservative I mean "everything is a source of a dependency, and
> > hence can't be removed, reordered or otherwise fiddled with", and that
> > includes code sequences where no atomic objects are anywhere in sight [1].
> > In the light of that the only realistic way (meaning to not have to
> > disable optimization everywhere) to implement consume as currently
> > specified is to map it to acquire. At which point it becomes pointless.
>
> No, only memory_order_consume loads and [[carries_dependency]]
> function arguments are sources of dependency chains.
However, that is, given how the standard specifies things, just one of
the possible ways for how an implementation can handle this. Treating
[[carries_dependency]] as a "necessary" annotation to make exploiting
mo_consume work in practice is possible, but it's not required by the
standard.
Also, dependencies are specified to flow through loads and stores
(restricted to scalar objects and bitfields), so any load that might
load from a dependency-carrying store can also be a source (and that
doesn't seem to be restricted by [[carries_dependency]]).