Paul E. McKenney via llvm-dev
2016-Feb-18 01:10 UTC
[llvm-dev] 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
Tony V E via llvm-dev
2016-Feb-20 02:15 UTC
[llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition
There's at least one easy answer in there:> If implementations must support annotation, what form should thatannotation 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 [[]] Sent from my BlackBerry portable Babbage Device Original Message From: Paul E. McKenney Sent: Thursday, February 18, 2016 4:58 AM To: parallel at lists.isocpp.org; linux-kernel at vger.kernel.org; linux-arch at vger.kernel.org; gcc at gcc.gnu.org; llvm-dev at lists.llvm.org Reply To: parallel at lists.isocpp.org Cc: peterz at infradead.org; j.alglave at ucl.ac.uk; will.deacon at arm.com; dhowells at redhat.com; Ramana.Radhakrishnan at arm.com; luc.maranget at inria.fr; akpm at linux-foundation.org; Peter.Sewell at cl.cam.ac.uk; torvalds at linux-foundation.org; mingo at kernel.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 at lists.isocpp.org Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel Link to this post: http://lists.isocpp.org/parallel/2016/02/0040.php
Paul E. McKenney via llvm-dev
2016-Feb-20 19:53 UTC
[llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition
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 at lists.isocpp.org; linux-kernel at vger.kernel.org; linux-arch at vger.kernel.org; gcc at gcc.gnu.org; llvm-dev at lists.llvm.org > Reply To: parallel at lists.isocpp.org > Cc: peterz at infradead.org; j.alglave at ucl.ac.uk; will.deacon at arm.com; dhowells at redhat.com; Ramana.Radhakrishnan at arm.com; luc.maranget at inria.fr; akpm at linux-foundation.org; Peter.Sewell at cl.cam.ac.uk; torvalds at linux-foundation.org; mingo at kernel.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 at lists.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 at lists.isocpp.org > Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel > Link to this post: http://lists.isocpp.org/parallel/2016/02/0045.php
Possibly Parallel Threads
- [isocpp-parallel] Proposal for new memory_order_consume definition
- Proposal for new memory_order_consume definition
- [isocpp-parallel] Proposal for new memory_order_consume definition
- [isocpp-parallel] Proposal for new memory_order_consume definition
- [isocpp-parallel] Proposal for new memory_order_consume definition