Re: [RFC][PATCH 0/5] arch: atomic rework

From: Torvald Riegel
Date: Wed Feb 26 2014 - 19:53:55 EST


On Wed, 2014-02-26 at 18:43 +0000, Joseph S. Myers wrote:
> On Wed, 26 Feb 2014, Torvald Riegel wrote:
>
> > 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).
>
> Regardless of the ABI, my point is that if a program is valid, it is also
> valid when all uses of [[carries_dependency]] are removed. If a function
> doesn't use [[carries_dependency]], that means "dependencies may or may
> not be carried through this function". If a function uses
> [[carries_dependency]], that means that certain dependencies *are* carried
> through the function (and the ABI should then specify what this means the
> caller can rely on, in terms of the architecture's memory model). (This
> may or may not be useful, but it's how I understand C++11.)

I agree. What I tried to point out is that it's not the case that an
*implementation* can just ignore [[carries_dependency]]. So from an
implementation perspective, the attribute does have semantics.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/