lkml.org 
[lkml]   [2014]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 0/5] arch: atomic rework
    From
    Date
    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.



    \
     
     \ /
      Last update: 2014-02-27 02:41    [W:2.896 / U:0.256 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site