[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1393420157.28840.8691.camel@triegel.csb>
Date: Wed, 26 Feb 2014 14:09:17 +0100
From: Torvald Riegel <triegel@...hat.com>
To: "Joseph S. Myers" <joseph@...esourcery.com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Michael Matz <matz@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Will Deacon <will.deacon@....com>,
Peter Zijlstra <peterz@...radead.org>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
David Howells <dhowells@...hat.com>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mingo@...nel.org" <mingo@...nel.org>,
"gcc@....gnu.org" <gcc@....gnu.org>
Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
On Fri, 2014-02-21 at 22:10 +0000, Joseph S. Myers wrote:
> On Fri, 21 Feb 2014, Paul E. McKenney wrote:
>
> > This needs to be as follows:
> >
> > [[carries_dependency]] int getzero(int i [[carries_dependency]])
> > {
> > return i - i;
> > }
> >
> > Otherwise dependencies won't get carried through it.
>
> C11 doesn't have attributes at all (and no specification regarding calls
> and dependencies that I can see). And the way I read the C++11
> specification of carries_dependency is that specifying carries_dependency
> is purely about increasing optimization of the caller: that if it isn't
> specified, then the caller doesn't know what dependencies might be
> carried. "Note: The carries_dependency attribute does not change the
> meaning of the program, but may result in generation of more efficient
> code. - end note".
I think that this last sentence can be kind of misleading, especially
when looking at it from an implementation point of view. How
dependencies are handled (ie, preserving the syntactic dependencies vs.
emitting barriers) must be part of the ABI, or things like
[[carries_dependency]] won't work as expected (or lead to inefficient
code). Thus, in practice, all compiler vendors on a platform would have
to agree to a particular handling, which might end up in selecting the
easy-but-conservative implementation option (ie, always emitting
mo_acquire when the source uses mo_consume).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists