Message-ID: <CAA+UVZQtzmY3Df8kh_9k5KXstephApm1cWhKumXLVNRetFqGtQ@mail.gmail.com>
Date:	Fri, 26 Feb 2016 15:56:59 -0800
From:	Lawrence Crowl <Lawrence@...wl.org>
To:	parallel@...ts.isocpp.org
Cc:	linux-arch@...r.kernel.org, gcc@....gnu.org,
	p796231 <Peter.Sewell@...cam.ac.uk>, llvm-dev@...ts.llvm.org,
	will.deacon@....com, linux-kernel@...r.kernel.org,
	dhowells@...hat.com, peterz@...radead.org,
	Ramana.Radhakrishnan@....com, Luc Maranget <luc.maranget@...ia.fr>,
	akpm@...ux-foundation.org, Jade Alglave <j.alglave@....ac.uk>,
	torvalds@...ux-foundation.org, mingo@...nel.org
Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition

On 2/25/16, Hans Boehm <boehm@....org> wrote:
> If carries_dependency affects semantics, then it should not be an
> attribute.
>
> The original design, or at least my understanding of it, was that it not
> have semantics; it was only a suggestion to the compiler that it should
> preserve dependencies instead of inserting a fence at the call site.
> Dependency-based ordering would be preserved in either case.

Yes, but there is a performance penalty, though I do not know how severe.
When do the pragmatics become sufficiently severe that they become
semantics?

> But I think we're moving away from that view towards something that doesn't
> quietly add fences.
>
> I do not think we can quite get away with defining a dependency in a way
> that is unconditionally preserved by existing compilers, and thus I think
> that we do probably need annotations along the dependency path.  I just
> don't see a way to otherwise deal with the case in which a compiler infers
> an equivalent pointer and dereferences that instead of the original.  This
> can happen under so many (unlikely but) hard-to-define conditions that it
> seems undefinable in an implementation-independent manner. "If the
> implementation is able then <the semantics change>" is, in my opinion, not
> acceptable standards text.
>
> Thus I see no way to both avoid adding syntax to functions that preserve
> dependencies and continue to allow existing transformations that remove
> dependencies we care about, e.g. due to equality comparisons.  We can
> hopefully ensure that without annotations compilers break things with very
> low probability, so that there is a reasonable path forward for existing
> code relying on dependency ordering (which currently also breaks with very
> low probability unless you understand what the compiler is doing).  But I
> don't see a way for the standard to guarantee correctness without the added
> syntax (or added optimization constraints that effectively assume all
> functions were annotated).
>
> On Sat, Feb 20, 2016 at 11:53 AM, Paul E. McKenney <
> paulmck@...ux.vnet.ibm.com> wrote:
>
>> On Fri, Feb 19, 2016 at 09:15:16PM -0500, Tony V E wrote:
>> > There's at least one easy answer in there:
>> >
>> > > ‎If implementations must support annotation, what form should that
>> >       annotation take?  P0190R0 recommends the [[carries_dependency]]
>> >       attribute, but I am not picky as long as it can be (1) applied
>> >       to all relevant pointer-like objects and (2) used in C as well
>> >       as C++.  ;-)
>> >
>> > If an implementation must support it, then it is not an annotation but
>> > a
>> keyword. So no [[]]
>>
>> I would be good with that approach, especially if the WG14 continues
>> to stay away from annotations.
>>
>> For whatever it is worth, the introduction of intrinsics for comparisons
>> that avoid breaking dependencies enables the annotation to remain
>> optional.
>>
>>                                                         Thanx, Paul
>>
>> > Sent from my BlackBerry portable Babbage Device
>> >   Original Message
>> > From: Paul E. McKenney
>> > Sent: Thursday, February 18, 2016 4:58 AM
>> > To: parallel@...ts.isocpp.org; linux-kernel@...r.kernel.org;
>> linux-arch@...r.kernel.org; gcc@....gnu.org; llvm-dev@...ts.llvm.org
>> > Reply To: parallel@...ts.isocpp.org
>> > Cc: peterz@...radead.org; j.alglave@....ac.uk; will.deacon@....com;
>> dhowells@...hat.com; Ramana.Radhakrishnan@....com; luc.maranget@...ia.fr;
>> akpm@...ux-foundation.org; Peter.Sewell@...cam.ac.uk;
>> torvalds@...ux-foundation.org; mingo@...nel.org
>> > Subject: [isocpp-parallel] Proposal for new memory_order_consume
>> definition
>> >
>> > Hello!
>> >
>> > A proposal (quaintly identified as P0190R0) for a new
>> memory_order_consume
>> > definition may be found here:
>> >
>> > http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf
>> >
>> > As requested at the October C++ Standards Committee meeting, this
>> > is a follow-on to P0098R1 that picks one alternative and describes
>> > it in detail. This approach focuses on existing practice, with the
>> > goal of supporting existing code with existing compilers. In the last
>> > clang/LLVM patch I saw for basic support of this change, you could
>> > count
>> > the changed lines and still have lots of fingers and toes left over.
>> > Those who have been following this story will recognize that this is
>> > a very happy contrast to work that would be required to implement the
>> > definition in the current standard.
>> >
>> > I expect that P0190R0 will be discussed at the upcoming C++ Standards
>> > Committee meeting taking place the week of February 29th. Points of
>> > discussion are likely to include:
>> >
>> > o     May memory_order_consume dependency ordering be used in
>> > unannotated code? I believe that this must be the case,
>> > especially given that this is our experience base. P0190R0
>> > therefore recommends this approach.
>> >
>> > o     If memory_order_consume dependency ordering can be used in
>> > unannotated code, must implementations support annotation?
>> > I believe that annotation support should be required, at the very
>> > least for formal verification, which can be quite difficult to
>> > carry out on unannotated code. In addition, it seems likely
>> > that annotations can enable much better diagnostics. P0190R0
>> > therefore recommends this approach.
>> >
>> > o     If implementations must support annotation, what form should that
>> > annotation take? P0190R0 recommends the [[carries_dependency]]
>> > attribute, but I am not picky as long as it can be (1) applied
>> > to all relevant pointer-like objects and (2) used in C as well
>> > as C++. ;-)
>> >
>> > o     If memory_order_consume dependency ordering can be used in
>> > unannotated code, how best to define the situations where
>> > the compiler can determine the exact value of the pointer in
>> > question? (In current defacto implementations, this can
>> > defeat dependency ordering. Interestingly enough, this case
>> > is not present in the Linux kernel, but still needs to be
>> > defined.)
>> >
>> > Options include:
>> >
>> > o     Provide new intrinsics that carry out the
>> > comparisons, but guarantee to preserve dependencies,
>> > as recommended by P0190R0 (std::pointer_cmp_eq_dep(),
>> > std::pointer_cmp_ne_dep(), std::pointer_cmp_gt_dep(),
>> > std::pointer_cmp_ge_dep(), std::pointer_cmp_lt_dep(),
>> > and std::pointer_cmp_le_dep()).
>> >
>> > o     State that -any- comparison involving an unannotated
>> > pointer loses the dependency.
>> >
>> > o     How is the common idiom of marking pointers by setting low-order
>> > bits to be supported when those pointers carry dependencies?
>> > At the moment, I believe that setting bits in pointers results in
>> > undefined behavior even without dependency ordering, so P0190R0
>> > kicks this particular can down the road. One option that
>> > has been suggested is to provide intrinsics for this purpose.
>> > (Sorry, but I forget who suggested this.)
>> >
>> > Thoughts?
>> >
>> > Thanx, Paul
>> >
>> > _______________________________________________
>> > Parallel mailing list
>> > Parallel@...ts.isocpp.org
>> > Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
>> > Link to this post: http://lists.isocpp.org/parallel/2016/02/0040.php
>> > _______________________________________________
>> > Parallel mailing list
>> > Parallel@...ts.isocpp.org
>> > Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
>> > Link to this post: http://lists.isocpp.org/parallel/2016/02/0045.php
>>
>> _______________________________________________
>> Parallel mailing list
>> Parallel@...ts.isocpp.org
>> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
>> Link to this post: http://lists.isocpp.org/parallel/2016/02/0046.php
>


-- 
Lawrence Crowl

Powered by blists - more mailing lists